What feature would you like to see most in Ice?

[xiehua]

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.

[damingyipai]

Originally posted by xiehua
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.

publish a Ice extension for IIS(ISAPI), and module for Apache?....

[damingyipai]

Usually, the web server is IIS or apache... etc

[andreynech]

HI,

Are there any plans to support IPv6 in ICE? If not, I think it would be nice-to-have
feature.


Thanks,
Andrey.

[marc]

Supporting this is trivial. We do this as soon as IPv6 becomes relevant

[peter.s]

i very much would like to see if Ice would have some build system instead of the config/Make.rules system.

especially the autotools framework comes to my mind because with this framework dependencies can easily be tracked and various platforms can easily be checked and supported.

i'm currently trying to run Ice on 64bit alpha linux and 32bit ppc linux and perhaps soon on mipsel linux and autotools would make this job much easier ;-)

[hvr]

Originally posted by peter.s
i very much would like to see if Ice would have some build system instead of the config/Make.rules system.

especially the autotools framework comes to my mind because with this framework dependencies can easily be tracked and various platforms can easily be checked and supported.

i'm currently trying to run Ice on 64bit alpha linux and 32bit ppc linux and perhaps soon on mipsel linux and autotools would make this job much easier ;-)

I've run into similiar problems... every new platform requires me to hack the rules... something that a well made autotools-based package doesn't require me to...
not that the autotools framework is perfect, but once done right, it works like a charm...
not to mention other features like cross-compilation, srcdir!=builddir builds and easier packaging for deb's or rpm's...

There _are_ software packages that are not such a good candidate for autotool'ification (such as unix kernels or low level hardware accessing software) but Ice doesn't fall into this category imho;

[feline]

Two things I would like to see....

1) Usage of poll() instead of select() on those platforms which support it. This would work around file descriptor limitations. Most select implementations are built on poll(). You will likely find that poll() will simplify the code too as you will not need to mess around with fd_set's anymore.

2) Never allow the server to connect to the client. This is mainly pertinent with respect to callbacks. Having to use a single glacier instance for each client connection is a pain. It should be possible to re-use the client to server connection for delivering the callback. (I say this out of ignorance to ICE internals ofcourse

[marlowa]

Originally posted by marc
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).

There are at least two stds, PGM and its successor NORM. Both have several open source reference implementations. The code for NORM seems to be in a better state, the PGM code I have seen is based on a version created for BSD which requires kernel mods. The NORM implementation I looked at is portable and requires no kernel mods. Take a look at http://norm.pf.itd.nrl.navy.mil for more details.

Regards,

Andrew Marlow.

[damingyipai]

Can ICE support WebService by it-self? that can give me more time in my logic coding...

and, how to use slice2wsdl?

[marc]

Originally posted by damingyipai
Can ICE support WebService by it-self? that can give me more time in my logic coding...

and, how to use slice2wsdl?

No, Ice does not have built-in support for SOAP or other Web-services stuff.

We used to use the SOAP data encoding for our persistance service "Freeze", and XML-schemas for versioning of Freeze data. However, we dumped this approach completely, because it was bloated, complicated, and slow. Now Freeze uses the Ice data encoding, and a Slice-based versioning mechanism. The new version is much cleaner, faster, and easier to use. (See the chapter about FreezeScript in the manual.)

Perhaps we will add a SOAP interface to allow communications with Web services in the future, but so far there was not a lot of demand for such a feature.

[michi]

Originally posted by marlowa
The NORM implementation I looked at is portable and requires no kernel mods. Take a look at http://norm.pf.itd.nrl.navy.mil for more details.

Looks interesting, thanks for the link. I'll put this on my (rather long) TODO list. But no promises as to time frame!

Cheers,

Michi.

[Yunqiao Yin]

Provide more communication protocol options,such as:
Unix Domain Socket,Shared Memory,etc.

[happysoft]

i want to development of ice integrated develop tools!

[marc]

Originally posted by Yunqiao Yin
Provide more communication protocol options,such as:
Unix Domain Socket,Shared Memory,etc.

I don't think Unix Domain Sockets are faster than TCP/IP loopback. Do you have any performance figures?

Shared memory can be faster for large requests. For short requests, the overhead for communicating shared memory state change is usually higher than sending the whole request over TCP/IP.

I implemented a shared memory transport for some other middleware project a few years ago. But the technical complexity and limited usability (only good for very large requests, and only works on the same machine) made me abandon this project.