Archived

This forum has been archived. Please start a new discussion on GitHub.

What feature would you like to see most in Ice?

123457

Comments

  • Can you develop a mapping for actionscript3.0

    Same as the title.
  • IceStorm should remember all subscribers

    I think IceStorm should persistent all subscribers' proxies in freeze db. When IceStorm restart, it can resume all subscribers's connections. I think this feature can make IceStorm more robust.
  • Provide an official ANTLR grammar for Slice

    This way, any of the 8152 counted by Michi in its september foreword can have its own translator and code generator.
  • annekat wrote:
    This way, any of the 8152 counted by Michi in its september foreword can have its own translator and code generator.

    I shudder at the thought of 8512 language mappings for Ice... ;)

    Cheers,

    Michi.
  • Can Ice support Turbo Delphi?
    There're free version of Delphi: http://www.turboexplorer.com
  • Ice could support Delphi .NET, but there is no cost-effective way to support Ice for Delphi 6. If you have a commercial need for Ice with Delphi .NET, please contact us at info@zeroc.com.

    Cheers,

    Michi.
  • Support MQ

    As a middleware platform,it is not perfect without supporting MQ.
  • Support cygwin

    I really think it is a good thing to programing ICE with Eclipse becuase it provides a very similar development environment for CPP and java,in particular, due to Ice is a multiple language middleware. In this sense, IMHO,Supporting cygwin is very different from supporting other platforms;) .
  • marc
    marc Florida
    You now made the same request in three different posts... I think we now know your desire to get cygwin supported :) In any case, I can promise you that it won't happen (at least not from ZeroC) until there is some commercial need for this feature. It's just like with the often-requested support for Borland Delphi: as long as nobody is willing to pay the bill, we can't do such a development just for fun.
  • O.K. O.K. :) .

    I am like a suspect and Marc is like a policeman or a killer, who is tightly after me no matter where I run to, just want say a word to me: NO. :p

    Any way, thank you Marc for ICE. It is really a good stuff especially for me, I have spent whole one year to study it and use it and it was a good experience and memory. Seriously, although I can not understand some support policies of yours, I think it is better for creators to provide more opporunities to share their masterpiece with more people. On the other hand, even if it is a excellent stuff but not known by many people, it may disapear eventually, after all, noting is impossible to be substituted nowadays.
    Now I have to return the orignal topic on Eclipse again. I disagree with you that supporting Eclipse in windows is only a fun. I insisted on thinking it will promote ,or accelerate the popularity of ICE by the help of Eclipse in windows and the more people use it, the more money zeroc can gain. Again, I disagree it is a same thing to supporting Borland CPP as Eclipse. BC is fading but Eclipse is growing. I believe commercial-driven development may be right but It is not always right. Of course , sometimes, the future of a production is depend on the company's foresight and ambition.:)
    I don't know if it is well known in other countries, it is not at least in China.
    As a fan of ICE, I try to tell guys I know to use it ,and feel it is a sell point to tell them they can use eclipse to develop Windows ICE program,especially for some companis, which strictly refuse the pirate,of here Visual studio .
    There is one truth I think we should understand, ICE is not the only technology people can choose. Before you want more commerical requests, at least, you have to persuade people to use it. Only some tiny efforts can give hesitating people more conveniences and interests in it, I do not think it is the same thing to supporting some commercial requests.:)

    Sorry, Marc, I don't wan to offend you since you are one of my idols and I benifit much from you guys' excellent works. Most of my distributed programing knowledges come from ICE. I just want more and more people can like ICE and adopt ICE. So I have some tiny words on your supporting policy. :)

    Anyway, as a open source project, you all have not any obligation or responsibility to support anything. I know it very much.

    Thank you again.
  • Also add stream methods for Freeze Map Codec classes

    add --stream option for slice2freeze, make it easy to use Freeze Map with Ice dynamic interfaces.
  • bernard
    bernard Jupiter, FL
    slice2freeze generates Freeze maps and other helper classes.

    --stream generates helper functions to pass Slice types "over the wire" through Slice-defined operations.

    So I don't see what slice2freeze --stream would do. Classes generated by slice2freeze don't go "over the wire".

    This thread is not a good place for feature discussion, so please start a new thread that describes the dynamic interface you'd like to see on Freeze.

    Cheers,
    Bernard
  • MOM features

    Hi,

    Some features I would like to have.

    MOM features in IceStorm :
    -message priority,
    -queue protected against loss,
    -deferred/persistence for later delivery of messages.

    Antonio.
  • marc wrote: »
    Supporting this [IPv6] is trivial. We do this as soon as IPv6 becomes relevant ;)

    Three years have passed since the above statement was made. Today, a google of IPv4 yields 9M hits. A google of IPv6 yields 16M hits.

    Does ICE now support IPv6? (I searched the PDF version of the ICE 3.2.0 manual, but found no reference to IPv6.)
  • marc
    marc Florida
    feathers wrote: »
    Three years have passed since the above statement was made. Today, a google of IPv4 yields 9M hits. A google of IPv6 yields 16M hits.

    Does ICE now support IPv6? (I searched the PDF version of the ICE 3.2.0 manual, but found no reference to IPv6.)

    No, Ice does not support IPv6. So far no customer has ever required this feature, therefore we have not implemented it.
  • "If you build it, they will come." - Field of Dreams (1989)
  • matthew
    matthew NL, Canada
    "Show me the money" - Jerry Maguire (1996)
  • SSL support in ICE-E !
  • matthew wrote: »
    "Show me the money" - Jerry Maguire (1996)

    Matthew, always with the riposte ;)
  • Actual entry in the Windows Registry

    This "feature" is not exactly about Ice but about its Windows installer. Please, make it create an actual folder under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall (or event better, under HKEY_LOCAL_MACHINE\Software\ZeroC). Currently the folder name under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Uninstall is autogenerated (or it looks like that), making it impossible to reliable find the location of Ice.

    Thank you.
  • I think it would be great if ICE support transaction (I mean database transaction, two phase commit like setcomplete() / setabort() feature in DCOM /COM+, or Java transaction). It will promote ICE as direct replacement of Microsoft COM+, but run on multiplatform.
  • Event Filtering

    I, too, would love to see Event Filtering for IceStorm. It is such a fundamental necessity in an event channel.

    Pete
  • Python loadSlice should allow for parsing of string

    I have a simple client model for periodically reporting some statistics on a machine.
    Given that the machines already have rpms for Ice in python on the machine, using loadSlice() is appealing in that I will not have to regenerate any files if the rpms are upgraded and slice2py requires some changes.

    loadSlice is nice - in that I can parse a slice file - but it requires an additional file to be distributed with this otherwise one file client. It would be nice if there was an equivalent to loadSlice that would parse a string and not just a file... I could probably hack it up to have the python script create a temporary file and dump the contents there for parsing - but as I said - a hack....

    Looking under the hood - this would be a non-trivial change...

    Ezra
  • ObjectAdapter with time based Objects lifetime

    A big problem with Ice is tracking object lifetime for object created and owned by clients. Tipically this objects are created by Factories with UUID Identity and the responsability to destroy them is leaved to the client. What happen if a client doesn't destroy them (for network problems or bugs)?
    It wuold be very nice to be able to register object with timeout. An object adapter able to destroy object not accessed for a configurable period of time.
  • xdm
    xdm La Coruña, Spain
    Hi paolo,

    You can already do that with a Timer in your servant implementation, i think
    that there is no need for such a change, there are lot´s of diferent scenarios for objects life time and no one is better for all kind of applications, is better implement it in the application layer.

    There are several examples in Ice sources of how do what you describe.

    look at demo/Ice/session , demo/Glacier2/chat in Ice sources
    Also is interesting the Article "The Grim Reaper: Making Objects Meet Their Maker" wrote by michi in newsletter 3.

    http://www.zeroc.com/newsletter/issue3.pdf

    Hope this help
  • Shared memory for machine local IPC

    I find myself quite frequently running servants in multiple processes but all on the same machine. It would be very cool if ICE were able to communicate via shared memory for machine-local connections. I haven't really looked into how ICE implements network comms on a local machine ---- it's entirely possible that through some combination of memory mapping and zero-copy network calls that a similar effect is already achieved.
  • drewb3 wrote: »
    IIt would be very cool if ICE were able to communicate via shared memory for machine-local connections.

    Whether this is worth it depends on the implementation of the loopback adapter in the OS. On some versions of Unix for example, it turns out that talking via loopback is actually faster than using shared memory.

    It's also questionable whether any performance gain is really needed. Comms over loopback is very fast already, with data transfer rates in the hundreds of megabit range. To realize any performance gain because of faster comms for the (local) RPC, you would have to have operations that transmit an enormous amount of data, yet do essentially nothing with the data. (Otherwise, the processing of the data in the operation body will swamp the cost of transmission.) But such operations basically don't exist in real applications. If there is a lot of data transmitted, the application will do something with that data, such as perform I/O on it, or do some computation; this data processing is likely to outweigh the cost of transmission.

    So, while a benchmark might show a performance gain due to a shared memory transport on some operating systems, no such performance gain would be realized by actual applications (other than a minor reduction in CPU consumption).

    So, overall, adding a shared memory transport is unlikely to be of any real benefit. And it would have a down-side as well, namely, to make the Ice core more complex, as well as the configuration.

    Cheers,

    Michi.
  • I strong suggest supporting mysql

    I strong suggest supporting mysql, oracle...
    And I hope there is a ORM in future like Hibernat for Java.
    Is this a dream or does this never become true?
  • xdm
    xdm La Coruña, Spain
    I strong suggest supporting mysql, oracle...
    And I hope there is a ORM in future like Hibernat for Java.
    Is this a dream or does this never become true?

    Hi,

    What kind of support are you thinking about, could you elaborate this a bit more?

    Currently you could use any of these databases with Ice, so what do you think would be helpful to made it easy to use?

    Cheers,
    José
  • Two things I'd like to see

    Suggestion one comes with the firm caveat that if there's already a solution to the problem it's intended to solve I'd quite happily drop the suggestion if the solution be made known :-)

    I'd like a 'reaper-on-steroids' that would more formalise the reaper pattern. This would make handling connection-oriented traffic easier. ( eg. interaction between short-lived guis and servers)

    In an ideal world sending the same message to multiple guis should be a case of looping over a collection of proxies and making the appropriate one-way call. However if you don't know if the gui at the end of a given proxy is still alive there's a reasonable amount of boilerplate that needs to be wrapped around the call to do this checking. The reaper pattern is fine but from what I can tell needs to be re-coded for each interface you want to implement it over, and it's still 'blind' if say if a bidirectional connection has gone down since the last 'reap' occurred ( this point is more pronounced for guis that recieve multiple updates per second). If a bidirectional connection has disconnected and the OS has received the socket close message I think it's reasonable that client code to be given some programatic means of being informed. I've read the comments on why this *isn't* a good thing in other contexts and they're well received and appreciated, but I'd make the point that for these reaonably broad use cases it's very useful functionality. Of course the failures that occur if, say, a network cable is snipped or a router crashes would also need to be handled, but surely these two means of detecting disconnection don't have to be mutually exclusive right?

    Having something that wraps a proxy, and handles the implementation of the reaper pattern ( or moral equivalent ) but with the addition of fast notification if the socket is closed would be great.

    A proxy ( or wrapper class ) with the following methods added in addition to the existing proxy methods would be great...

    setHeartbeatInterval( long ms);
    setTimeoutOnMissedHeartBeats( int failures);
    addConnectionStatusCallback( IConnectionCallback cb);

    Where IConnectionCallback would look somethign like ..
    IConnectionCallback
    {
    void onTimeOut( Proxy prx);
    void onDisconnect( Proxy prx);
    }

    ===============================================

    Request two is think is simpler. This is java specific but I guess could apply equally to the other language implementations. I'd find it useful if an "immutable" or "final" annotation could be applied to slice members such that the emitted structs were final and contained only final members. There are good reasons why typically a given class/struct in 'normal' code should be made immutable so I feel it'd be a useful addition to the generated code as well.

    Main justifications would be thread-safety, efficiency and robustness of code ( robustness in this context being immunity to user-errors).

    Thanks,

    SM.