Archived

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

What feature would you like to see most in Ice?

245678

Comments

  • Re: What feature would you like to see most in Ice?
    Originally posted by marc
    We would like to get a feeling for what features are on top of your wish list. So, what features are you missing in Ice?

    Please feel free to suggest anything that comes to your mind, including, but not limited to, new language mappings, new services, new core features, documentation enhancements, etc.

    I'd like to see Value Object for Ice where object attributed values are cached and read only locally and update is only permitted from remote. This would be useful feature for online games.
  • Originally posted by chaukmean
    Right.

    But a reliable multicast for delivering ICE requests can be built on top of UDP multicast.

    Yes, of course it could. But I simply don't feel that Ice is the right abstraction level for doing this. I would much prefer to use an existing reliable multicast protocol and add it to Ice as a protocol plug-in.
    Originally posted by chaukmean
    What about RT CORBA like features ?

    Chauk-Mean.

    This would be a very good addition to Ice, and it's on our TODO list. The reason why I started this thread was to find out what is most important to Ice users, and to adjust the priorities on our TODO list accordingly.
  • Originally posted by marc
    Yes, of course it could. But I simply don't feel that Ice is the right abstraction level for doing this. I would much prefer to use an existing reliable multicast protocol and add it to Ice as a protocol plug-in.
    JavaGroups offers reliable multicast communication. CORBA will offer the same kind of feature with ROMIOP (Reliable Ordered Multicast Inter-Orb-Protocol). I hope you will change your mind and that ICE will support in the near future a reliable multicast communication.
    Originally posted by marc
    This would be a very good addition to Ice, and it's on our TODO list. The reason why I started this thread was to find out what is most important to Ice users, and to adjust the priorities on our TODO list accordingly.

    Please put RTCORBA like features at the top of the list (after a reliable multicast communication : - ) )

    Chauk-Mean.
  • Originally posted by chaukmean
    JavaGroups offers reliable multicast communication. CORBA will offer the same kind of feature with ROMIOP (Reliable Ordered Multicast Inter-Orb-Protocol). I hope you will change your mind and that ICE will support in the near future a reliable multicast communication.

    Well, just because the OMG releases yet another RFP for something, doesn't mean you'll see commercial quality implementations anytime soon :)
  • I'd like to see a big darn example Ice project that does something reasonably useful, and integrates the various existing features in non-canned ways.

    Don't get me wrong, the documentation is excellant, and the examples are presented quite well - from good to better to best. However, it would be really useful if ZeroC provided some complete application of moderate complexity, GPL'd of course, which really shows off it's product.

    Who's with me? (Or does this already exist?)
  • Originally posted by Ctaesis
    I'd like to see a big darn example Ice project that does something reasonably useful, and integrates the various existing features in non-canned ways.

    I'd like to see the same. It would be really cool to be able to discover some magic that the Ice creators can do with their middleware!

    What would be really interesting (I think I'll post this into the help section as well) would e.g. be an example that implements a Windows Service (and/ or a Unix daemon) that offers some Ice objects. It would be particularly interesting how the object reacts to freezes ('pause' action for Windows Services). Also, the general setup/ structure would be interesting.

    regs,

    Stephan
  • I'm currently involved in the development of a system for distributing user information across various systems at Norwegian universities. I came across Ice by accident, through the Wish beta actually. :) Having spendt some hours looking into it, the one reason I can see right now for us not choosing Ice is the lack of Python support.

    A bit late to get it for this project, but I would very much like to see a mapping for Python in the future.
  • Originally posted by silmaril
    A bit late to get it for this project, but I would very much like to see a mapping for Python in the future.

    One of the many things on the list of things we could do. Most likely, any Python implementation would be done as a language mapping on top of the C++ libraries. Maybe we'll tackle this once the C# implementation is done.

    Cheers,

    Michi.
  • IceJ 1.2.0 ;)

    Seriously, I'd like to see that Java implementation has the same or close functionality/number of implemented features as C++ one.
    Please, don't forget about IceJ.
  • mes
    mes California
    Originally posted by alexander
    Seriously, I'd like to see that Java implementation has the same or close functionality/number of implemented features as C++ one.
    Please, don't forget about IceJ.
    Can you be more specific?

    The Java implementation is just as important to us as the C++ implementation. The feature set of the two was determined very deliberately: we try to provide the same feature in both, unless there's a platform limitation that prevents it, or a compelling advantage (such as performance) that favors an implementation in only one language.

    As one example, it's not currently possible to implement IceSSL in Java due to JDK limitations. As soon as the JDK allows it, we will implement IceSSL in Java. Another example is a service such as IcePack, which (in our opinion) is more appropriately written in C++ given its responsibilities.

    Take care,
    - Mark
  • Originally posted by mes
    Can you be more specific?

    The Java implementation is just as important to us as the C++ implementation. The feature set of the two was determined very deliberately: we try to provide the same feature in both, unless there's a platform limitation that prevents it, or a compelling advantage (such as performance) that favors an implementation in only one language.

    As one example, it's not currently possible to implement IceSSL in Java due to JDK limitations. As soon as the JDK allows it, we will implement IceSSL in Java. Another example is a service such as IcePack, which (in our opinion) is more appropriately written in C++ given its responsibilities.

    Take care,
    - Mark

    It's easier to say what's implemented than what isn't ;)

    I agree that Java could be inappropriate platform for some services if your goal is a performance.

    However, sometimes I use your service implementations as a reference because, on my opinion, it's the best way to understand how some library supposes to be used.
    And C++ and Java implementations are pretty different so it's difficult to use C++ implementation as a reference for a Java programmer.

    I'm missing an example of Plugin which transparently extends base protocol by using encryption/compression/etc.
  • DII + DSI + Interface Repository

    Hi,

    One of my research projects is a scripting tool for CORBA, called LuaOrb. In the beginning of LuaOrb, the ORB provided by OOC was very important due to two reasons: its source code was available and it was a high quality (the best?) CORBA implementation. So, I am a big fan of the ZeroC folks! :)

    Now, I would love to develop a LuaIce tool.
    Since Lua is very popular among game developers, I believe it would be a good match.

    But I need some sort of DII, DSI and IFR!
    (if the Ice objects could keep their interface descriptions without the need of an external service (IFR), it would be great; but I would be happy with the IFR approach. ;) )

    Of course, I can implement a whole middleware from scratch in Lua, based only on the Ice protocol description. In fact, I am strongly considering this option too. But these two options are not completely equivalent, and I would need some sort of interface introspection facility in the Ice objects anyway.

    Unfortunately, I think it will take some time until we can have these dynamic features in Ice... or do you guys have good news for us about these features in Ice?? ;)

    Thanks,
    Renato

    PS: BTW, I am trying to port Ice to MacOS X. I built the whole stuff but it fails in the thread alive test.
  • mes
    mes California
    Re: DII + DSI + Interface Repository
    Originally posted by rcerq
    But I need some sort of DII, DSI and IFR!
    We don't have any immediate plans for capabilities like DII/DSI/IFR. However, as the person who implemented our client-side PHP mapping, I will say that doing dynamic requests in Ice is pretty straightforward already. The capabilities are all there in Ice, you just have to take advantage of them. In particular, you need the following:
    • The Slice parser. This is a library that you can link against, and takes the place of a separate IFR. After parsing your Slice files, you can traverse the parse tree quite easily using the Visitor pattern. It's much simpler than using the IFR.
    • The IceInternal::BasicStream class. This is the marshaling engine. Using the information about Ice operations obtained from the Slice parser, you can drive the marshaling for any request. I realize users may be reluctant to use a class in the IceInternal namespace, but until we have a better solution it's the only way to do it.
    • The ice_invoke proxy method. After marshaling the request into a sequence of bytes, you can invoke the operation using this method.
    Take a look at the source code for IcePHP if you'd like an example. I'd be happy to discuss this further, but we should probably do it in a separate thread.

    Take care,
    - Mark
  • The most important feature !

    The most important feature !
    1.work well with vc.net 2003
    2.work well with win98

    up to now,I can only Use Ice by DLL in vc.net 2003 ,when
    code ice into the vc.net 2003,there are many problems.
    There are so many .net progammers,So if 1. work well,It help
    more progammers to use Ice.

    up to now,I can't Use Ice Application in win98 client properly(not develop),
    Also there are so many people still use win98,if 2. work well,
    It help more progammers to use Ice.
  • bernard
    bernard Jupiter, FL
    What kind of problems do you have with Visual Studio .NET 2003?

    Also the next Ice release (sometimes in February) will support Windows 98.

    Cheers,
    Bernard
  • C# !!!!

    a C# version on MS .NET and Mono .NET is definitely highest on my wish list. Secondly, a UML(XMI) --> Slice mapping.

    Claes
  • Re: C# !!!!
    Originally posted by Claes
    a C# version on MS .NET and Mono .NET is definitely highest on my wish list. Secondly, a UML(XMI) --> Slice mapping.

    Claes

    A C# mapping is currently being written. Expect a first version in about two months.
  • Did you run into some issues with the C# mapping? There's a post around here with Michi implying that C# would come in the Feburary update. I'm not pushy, really. :D
  • Originally posted by Ctaesis
    Did you run into some issues with the C# mapping? There's a post around here with Michi implying that C# would come in the Feburary update. I'm not pushy, really. :D

    There are several issues with some C# libraries being very buggy, such as the network library. For details, you must wait until Michi is back, he is on travel and will be back at the end of next week.
  • There are several issues with some C# libraries being very buggy, such as the network library

    I don't mean to convert this to a C# centric discussion but if its not too much trouble could you (or Michi) please enumerate exactly what kind of issues youare facing with the buggy libraries? We are starting a project where we anticipate heavy network usage. If I could get a heads up, it'd be great.

    Furthermore we have direct contact with some Microsoft PM's who work in the C# team. We could even touchbase with them regarding the issues if you guys are interestsed.

    If you want to take this discussion offline you could email me at dilipxsl AT lycos DOT com

    thanks!
  • Not to derail this any further (but I guess I will somewhat anyway, *cough*), I'd be interested in hearing about the corlib bugs you're running into as well... perhaps Michi could make a new thread when he has time to do so.
  • Let me suggest that you start a new thread for this issue. Michi will respond as soon as he is back from his travels.
  • Hi,

    I'd love to see these, if possible:

    1. Define/document an object serialization standard for ICE (across languages) and implement it for the existing language bindings.

    2. New language bindings, such as: (a) Python and (b) a plugin for Mozilla/XUL.

    Regards,
    Shantanu
  • Mozilla is a web browser, and XUL is a UI description language right? How would you envision using Ice with them? I'm curious.
  • Mozilla, besides being a browser, also hosts an application development framework. Though (I just supposed) it's common to call it as Mozilla/XUL, it is not a technically correct term afterall. I admit.

    Instead, it is the XPCOM/XPConnect part of Mozilla using which the existing ICE libraries can be wrapped. XPCOM components can be written with C++, Python or JavaScript. XPConnect uses XPIDL (the interface definition language for XPCOM), which would require a mapping corresponding to Slice. More info on mozilla.org, mozdev.org etc.

    Mozilla has been gaining popularity of late and it already does SOAP; I believe it would be nice to see an ICE binding available as this might make enterprise-wide RAD deployment through Mozilla easier. You may like to take a look here, though this is not the only one:
    http://slashdot.org/article.pl?sid=04/01/17/1347204&mode=thread&tid=126&tid=154&tid=163&tid=95

    Regards,
    Shantanu
  • communication with IIOP !

    Can ICE replace the CORBA at short time? If not, this feature is important.
  • Re: communication with IIOP !
    Originally posted by damingyipai
    Can ICE replace the CORBA at short time? If not, this feature is important.

    Ice can do everything CORBA can do, and more.

    Interoperating with CORBA is not really an option because the object models are too different. For example, Ice does not provide unsigned integers, unions, arrays, fixed-point types, and a number of other things. At the same time, Ice adds some things that are missing from CORBA, such as exception inheritance, dictionaries, and facets. And other things are simply different, such as the different scoping rules of IDL and Slice. The resulting mismatch in object models is too large to sensibly bridge the two domains.

    As an aside, I have seen many attempts to create interoperability between object models before, such as CORBA-COM, CORBA-DCE, CORBA-GDMO, and others. In all cases, these attempts were failures because the mismatch in object models results in APIs that look like a dog's breakfast and no-one wants to use them.

    If you want to interoperate between CORBA and Ice, the best and most effective way is to write a proxy server that speaks Ice on one side and CORBA on the other. It's work, yes, but at least, that way, you are going to get an API that is usable, instead of a complete mess. And there is no reason why you can't link with both Ice and an ORB in the same executable.

    Cheers,

    Michi.
  • O/R Mapping support

    If the ICE support O/R mapping( like ODMG, ODL, OQL in CORBA ), it's better to me.
  • an useful feature !!!

    now Ice can use either tcp/ip or UDP as a transport.
    If Ice can use http also as a transport,It is so useful.
    In my country,always the computer client connect to the
    internet through a proxy server that only support http.
    So the client with Ice can't work in this case.