What feature would you like to see most in Ice?

[taweili]

Originally posted by salva
i 'd like see a light ICE for mobile phones, and PDA , and , could be interesting that Ice probides a simple SOAP iface?.

gSOAP provides a pretty decent environemnt for developing C/C++ based SOAP service. I have used that in a project before and was happy with it. I think integrating gSOAP with Ice won't be difficult and this can be used to provide SOAP interface for Ice Object.

A lite version of Ice protocol stack for phone and PDA would really be really interested.

[taweili]

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.

[marc]

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.

[chaukmean]

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.

[marc]

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

[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.

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?)

[stephan]

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

[silmaril]

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.

[michi]

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.

[alexander]

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]

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

[alexander]

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.

[rcerq]

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]

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

[xiehua]

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.