What feature would you like to see most in Ice?

[matthias]

Hi Marc,

since I am forced to Delphi & Kylix for most of my projects,
I would love to have Ice available for this platform.

Best regards,
Matthias

[andreynech]

Hi,

It would be nice if ICE components will be more like EJB/CCM Components, i.e. providing event sources/sinks and facets/receptacles. Having some kind of deployment descriptors for ICE Box where the connection between components are described and checked during deployment for compatibility (based on declared provided/expected interfaces) will also make life easier


Thanks,
Andrey.

[ganzuoni]

Hi,
there has already been a certain amount of discussion about
load balancing....
I think that a custom Locator approach it's quite clean because
allows pluggable balancing strategies, but there
must be an easy way to override getEndpoints behaviour in LocatorInfo
wrt the unconditionally use of the LocatorTable.
I think that there should be a way to force the call to
findObjectById on the corresponding locator, maybe specifying
patterns on identity category and/or name or, better,
giving the possibility to specify a predicate object with a

boolean cacheEndpoints(Ice.Identity id)

I would also recall my comment about the possibility to map
User exception to RuntimeException in java.

Regards,
Guido

[michi]

Originally posted by kssreeram
Right now ICE/win32 has an out-of-the box limit of 64 connections only. This is a very restrictive limit.

I changed this to 1024 some weeks ago, so the next released version fixes that. If you want this before then, change the definition of FD_SETSIZE in include/IceUtil/Config.h to what you'd like it to be.

Cheers,

Michi.

[michi]

Originally posted by kssreeram
I would love to see support for
Server-To-Client Callback Thru Client Initiated connections.

Right now this can be achieved using Glacier.
But I would LOVE to see an in-process solution without requiring a separate Glacier Process.

I was keen to do something like this a few weeks ago, but Marc convinced me that it is impossible -- there is no reliable way to identify the other party sufficiently reliably to decide when to send a request over an already open connection instead of a new connection: with NAT, routers, and firewalls in between client and server, the address in the proxy the server uses to make the request may in no way resemble the address that will be reported by the networking stack as belonging to the other end of a connection. So, as much as we'd like to make this transparent, I'm afraid we'll have to continue to use Glacier for this.

Cheers,

Michi.

[xdm]

Hellow everybody

I think that an Ice version for embedded systems can be a very nice think.

And I think that a documetation structured in classes can be very helpfull

gratefulls for Ice i think that is a very very good product

[SteveWampler]

Event filtering in IceStorm.

Support of 64-bit architectures (may already be there?) - Opteron and friends.

Stronger CCM support (echoing another user's comment...)

[marc]

Originally posted by SteveWampler
Support of 64-bit architectures (may already be there?) - Opteron and friends.

Ice runs on Sparc (64bit) and Opteron. At present, we don't have Opteron hardware anymore (we'll buy some new one soon), that's why we don't list it as supported platform. But we tested older versions of Ice on Opteron.

[chrisk]

Hi,

to pick up the idea of another poster: support for CORBA, i.e. IIOP. After all IDL and SLICE
are not too different, at least they share a "common subset". So for those things they have
in common compatibility would be great (of course as some sort of optional "plugin" to ICE,
not the default ).
Even though it would not allow to use the full set of features of either technology, it would
at least allow some sort of limited interop without having to "hand-craft" gateways for
every occasion you might need it.

Chris

[istvan]

Hi,

one feature I would be interested in is a mechanism similar to CORBA DII.
Along the same line, it would be really nice if the slice compiler could generate some code to allow the client to retrieve meta-data describing object interface. There is an interesting article on that subject at http://www.cuj.com/documents/s=8943/cujexp0312vinoski/ written by Steve Vinoski and Doug Schmidt. As Ice is already using XML and XML schemas for Freeze, I guess it would not be too difficult (easier to say than actually implementing it ) to use the same infrastructure to publish meta-data upon client request.

Istvan

[marc]

Originally posted by istvan
Hi,

one feature I would be interested in is a mechanism similar to CORBA DII.
Along the same line, it would be really nice if the slice compiler could generate some code to allow the client to retrieve meta-data describing object interface. There is an interesting article on that subject at http://www.cuj.com/documents/s=8943/cujexp0312vinoski/ written by Steve Vinoski and Doug Schmidt. As Ice is already using XML and XML schemas for Freeze, I guess it would not be too difficult (easier to say than actually implementing it ) to use the same infrastructure to publish meta-data upon client request.

Istvan

Actually, we dumped XML schemas completely from Freeze. It's too slow, too cumbersome. In Ice 1.2.0, we only store binary format in Freeze, and use native Slice code for our database transformer. Soon we will release a tool "FreezeScript" with even more possibilities to manage Freeze databases. XML is just too complicated and slow. The new transformer, which uses native Slice, is much, much easier to use. (XML being "simple" is complete nonsense in my opinion. As soon as you want to do anything but trivial stuff, XML is way too complicated...)

Sorry, but we're not sold on the XML hype XML is fine for stuff such as configuration, or as a "better HTML" (like our DocBook documentation), but beyond that, XML is just not the right tool. To me, the whole XML hype is another manifestation of the "I have a hammer, therefore everything else is a nail" problem. XML is good for some stuff, but now it's pushed into areas where it simply doesn't belong.

In any case, I agree with you that we need something like DII. However, this will definitely not use XML, but instead use parsed Slice code, just as IcePHP does.

[istvan]

Originally posted by marc

Sorry, but we're not sold on the XML hype XML is fine for stuff such as configuration, or as a "better HTML" (like our DocBook documentation), but beyond that, XML is just not the right tool. To me, the whole XML hype is another manifestation of the "I have a hammer, therefore everything else is a nail" problem. XML is good for some stuff, but now it's pushed into areas where it simply doesn't belong.

Don't be sorry, I'm actually very happy to read your answer. At my workplace CPU usage simply exploded since the "smart guys" decided that XML was THE answer for all our problems, so I perfectly understand your point of view.

[chaukmean]

Hi,

It would be great if ICE support RT CORBA like features.
I mean priority thread control (client propagated and server declared models), scheduling features, ...

Additionally, we have a strong need for multicast protocol. So if ICE also
support a reliable multicast protocol like the ROMIOP Request For Proposal
at the OMG, it would be very great.

Chauk-Mean

[marc]

Originally posted by chaukmean

Additionally, we have a strong need for multicast protocol. So if ICE also
support a reliable multicast protocol like the ROMIOP Request For Proposal
at the OMG, it would be very great.

The problem is that (to my knowledge) there is no official standard yet for reliable multicast, as there is for reliable unicast (TCP). Ice doesn't aim to try to invent basic internet protocols, but rather to put our object model on top of existing and proven protocols (like TCP or UDP).

[chaukmean]

Right.

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

What about RT CORBA like features ?

Chauk-Mean.