Archived

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

What feature would you like to see most in Ice?

1234568»

Comments

  • Event filtering in IceStorm. For example, a subscriber can subscribe to a topic and specify certain filters so the subscriber only gets messages that satisfy the specified filter.
  • Compare the Ice serialization with Protocol Buffers, Although Protocol Buffers did not support inheritance, it support [optional]. The optional feature could reduce the final serialization size without modified the slice structure.

    Hope ice serialization support the optional!
  • Bounded Sequences

    Since you asked, Marc, I'd like to see bounded sequences in Slice. I reviewed the documentation and this comments forum and couldn't find any mention of it but I'm sure this isn't a new concept for ICE.

    Basically, I'd like Slice to support cardinality bounds on sequences so that relationships like "0 or more", "at most N" or "between N and M" can be expressed. Syntax might be something like:

    sequence<Fruit> FruitPlatter;
    - 0 or more Fruits in a FruitPlatter

    sequence<Fruit>(5) FruitPlatter;
    - at least 5 Fruits in a FruitPlatter

    sequence<Fruit>(5,10) FruitPlatter;
    - between 5 and 10 (inclusive) fruits in a FruitPlatter

    sequence<Fruit>(,7) FruitPlatter;
    - no more than 7 fruits in a FruitPlatter


    The advantage of being able to do this is that:
    * you can make the "optional item" feature more concrete by using
    bounds of (0,1)
    * you can ensure that enormous sequences cannot be transmitted
    * you can enforce cardinality constraints that come with a particular
    application to be enforced at the interface level.

    Anyway, that's my $0.02 worth.
  • bernard
    bernard Jupiter, FL
    Hi Reid,

    Welcome to our forums! There is of course always a tension between keeping Ice/Slice small and simple and adding more features/Slice types.

    I think bounded sequence are fairly unusual--for example the standard C++ library does not have a bounded list or vector.
    The advantage of being able to do this is that:
    * you can make the "optional item" feature more concrete by using
    bounds of (0,1)

    That's of course a border case, and a special "optional" keyword/feature would be more readable than a (0, 1) bound.
    * you can ensure that enormous sequences cannot be transmitted

    Ice already provides this feature in a more general manner. See http://www.zeroc.com/faq/requestSizeLimit.html.
    * you can enforce cardinality constraints that come with a particular
    application to be enforced at the interface level.

    Because such types don't exist in the standard C++, Java etc libraries we would need to either manufacture our own C++/Java/etc types or more likely enforce these bounds at run-time, while marshaling/unmarshaling normal unbounded objects (std::vector, java.util.List etc). This does not buy much compared to a check in your implementation.

    If you want to follow-up, please create a new thread as we want to keep this thread focused!

    All the best,
    Bernard
  • rspencer wrote: »
    I'd like to see bounded sequences in Slice.

    I've written about this in the past. CORBA made a mistake by having three separate sequence abstractions in IDL: arrays, bounded sequences, and unbounded sequences. Yet, unbounded sequences are sufficient to model the other two.

    As far as IDL is concerned, having the extra sequence types adds a minor benefit in terms of static type safety.

    But the real problem isn't with the interface definition, it's with the various language mappings. While most languages have an array concept, most languages don't have a bounded sequence concept. And mapping the three separate abstractions into each language proved to be quite painful for CORBA. Especially in C++, it created an API that's full of pitfalls.

    For arrays, the problem is that in C++, if we map a Slice array to a C++ array, you end up with all the usual issues: possible array out-of-bounds access and memory management problems. In other words, mapping to raw arrays is pretty much useless (as evidenced by the CORBA mapping). To make arrays safe to use, we'd have to wrap them in a container of our design, but then they are no longer native arrays and can no longer be used like native arrays. The overhead in terms of additional code and learning curve is not worth the very minor gain in expressiveness at the Slice level.

    Similarly for bounded sequences: we'd have to invent our own constructs for each language mapping, adding to the size of the generated code and the learning curve. Moreover, such a home-grown data type then would be difficult to pass across native framework APIs and would not be natural to use. Again, it's simply not worth it.
    The advantage of being able to do this is that:
    * you can make the "optional item" feature more concrete by using
    bounds of (0,1)

    Yes. But this isn't need all that much, and the cure would be worse than the disease.
    * you can ensure that enormous sequences cannot be transmitted

    No, nothing can ensure that because a malicious client or server can always cobble together fake network packets with fake sequence sizes. With Ice, the receiver always holds all the unmarshaled data at arm's length to make sure that it is internally consistent. This ensures that the receiver does not over-commit on memory allocations during unmarshaling.
    * you can enforce cardinality constraints that come with a particular
    application to be enforced at the interface level.

    Yes, it would add that, but at a price that's not worth paying. Basically, the feature is needed rarely enough to make it a better option to have the application code enforce limits on the sequence length.

    Cheers,

    Michi.
  • Sending a point-to-point message through IceStorm

    It would be helpful to have a possibility to send point-to-point message through IceStorm which then will be consumed concurrently but only by one consumer and not duplicated across multiple consumers.
  • mes
    mes California
    Hi,
    It would be helpful to have a possibility to send point-to-point message through IceStorm which then will be consumed concurrently but only by one consumer and not duplicated across multiple consumers.
    IceStorm allows a publisher to send a message to a single subscriber, as described here. Does this solution meet your needs?

    Regards,
    Mark
  • mes wrote: »
    Hi,

    IceStorm allows a publisher to send a message to a single subscriber, as described here. Does this solution meet your needs?

    Regards,
    Mark

    I posted message after reviewing documentation and forum. If to do it "manually" then better to use usual Ice point2point mechanism. The trick is to push to Strom responsibility of delivering message to one of subscribers reliably. Didn't try approach described in manual by myself but as far as I understand there are 2 points that makes it not attractive:
    a) decision of choosing target has to be made by client thus loosing idea of decoupling them;
    b) most probably "the request is forwarded via IceStorm" means message could stuck if that specific subscriber gone;

    So idea is to let Storm to decide subscriber and ensure that message will be delivered to one of online subscribers.
  • ICE for .NET CF
    ICE for Android
    ICE for Symbian S60,S80.....

    I think Ice for mobile series will be success.
    Mobile GUI (or other embed device GUI) + distribute comunication...
  • Documentation, Documentation and Documentation...

    1) Documentation which contains a reasonably diverse collection of explained examples which are also included in the distribution "demo" folders, rather than a reoccurring trivial example which is not included in the distribution "demo" folders, and bears no resemblance to the approach used in the distributed "demo" folders (i.e. "Application" class).

    2) Documentation and distribution "demo" folders which include the "up-to-date" and corrected versions of the contents of the now defunct Newsletter technical articles, rather than having to dig around old articles and associated files which are now obsolete and no longer work (go-figure!).

    3) Documentation which stands on its own, rather than having to pay to have all the "holes" explained.
  • Test target needs to continue even after finding errors.

    I'd like to have the 'make test' script continue even if it encounters errors. It would be helpful to know what is not working from the spectrum of available capabilities.

    I'm porting to OpenSolaris and it has issues. It has enough functionality that ICE is useful, but it would be great if I could see what aspects of the entire package are non-functional.

    Also, there are demo packages that fail to build. I'd like them to be reported, but it would be good if I could just set a flag that would ignore these auxiliary targets. (I admit I did not look in the makefiles...)

    Thanks.
    Laszlo
  • dwayne
    dwayne St. John's, Newfoundland
    iCode wrote: »
    I'd like to have the 'make test' script continue even if it encounters errors. It would be helpful to know what is not working from the spectrum of available capabilities.

    'make test' just runs the allTests.py script. You can run this script manually and pass the --continue option to have the tests continue to run after a failure. Run "allTest.py --help" to see other options.
  • matthew
    matthew NL, Canada
    iCode wrote: »
    ...
    Also, there are demo packages that fail to build. I'd like them to be reported, but it would be good if I could just set a flag that would ignore these auxiliary targets. (I admit I did not look in the makefiles...)

    Thanks.
    Laszlo


    make -k ignores errors. Does that solve your problem?
  • Workaround.

    True to form, I simply coded around the problem. Created dummy C++ files that built without the error. There were only two, Glacier2/callback and Glacier2/chat.

    Everything else built OK. Subsequently there were only 5 problems with 'make test':

    13/71: testing sent callback - times out indefinitely
    25/71: testing dispatcher - times out indefinitely
    32/71: plug-in initialization failed
    36/71: testing udp multicast - ConnectFailedException (could be my DNS setup?)
    61/71: testing replication with ordered load balancing... failed

    However, the "Hello World" application is working which is all the capability I need for now.

    Thanks for the responses!
    Laszlo
  • Ice 3.4.1 MING32 /gcc.exe (tdm-1) 4.5.0

    My original post is here http://www.zeroc.com/forums/help-center/985-does-ice-support-mingw-2.html#post22403
  • In the spirit of the OP, I'd love to see support for Node.js in ZeroC Ice. It would save me so much time.
  • Please support Qt SDK

    Now Ice does not support Qt SDK. Qt SDK become more and more popular and important. At present, Qt Creator can not compile Ice programs on Windows ,because Qt Creator use mingw as it's compiler,but Ice does not support Mingw.
    If Ice support Qt Creator on Windows, I think it will be a big improvement.
  • QT & Ice on Windows

    Hallo,

    I do not know, what You mean, maybe it is some misunderstanding, but last time I checked You could have Qt and Ice playing nicely together on Windows; - when You use the Visual C++ compilers from Microsoft. Doing that will force You sooner or later, even when you start with the "express" version, into the proprietary corner, with all associated monetary and freedom costs.

    I personally did not want to go this way and tried to port Ice to the GCC compiler on windows, in my case, I choose the TDM edition for MinGW. I am not finished yet, although I did compile Ice and Qt and used them together on Windows. There is no documentation and I did nothing to reintegrate my changes. - But in case You are interested we can go together and try to do a MinGW port "properly".

    You can of course go the Linux way.

    Anyway, I wrote far too much ;-)

    Cheers,

    recoder
  • swaj wrote: »
    In the spirit of the OP, I'd love to see support for Node.js in ZeroC Ice. It would save me so much time.

    I know, right? I absolutely agree with that! That's exactly what I personally want!
  • support for the current stable Debian

    support for the current stable Debian — this is what I'm praying for.
  • Statistics & monitoring

    It would be very useful to have a statistic for Icestorm that could be input for monitoring. For example if IceStorm starts consuming more memory to find the root cause following information will be good to know (last 1/5/15 min and from the beginning ):

    How many queues exist?
    How many unsent messages are in each queue?
    How many workers are listening on what queues?

    Even simplest queue implementation have such info:
    Introducing RQ » nvie.com
  • bernard
    bernard Jupiter, FL
    Hi Oleh,

    I agree, we should provide more information about what's going on inside IceStorm.

    An increase in memory consumption can be due to one or more subscribers processing messages too slowly, however, unfortunately it's currently difficult to say for sure or identify these slow subscribers.

    Thanks for the feedback,
    Bernard
  • I would love to see additional option for slice2cpp to generate enum2string and string2enum functions. This should not break anything as would be disabled by default.
  • philip_lamb
    philip_lamb Christchurch, New Zealand

    Bluetooth LE support.

  • Support For golang,
    And also support http as a high available web server.

  • To support golang