What feature would you like to see most in Ice?

[mep]

Originally posted by chenhong_sz
All Ice Service(IcePack,IceBox,IceStrom...) can been build with user Application together,then these service can been run in different style: console, service(deamon),GUI Application.
as i know, TAO's corba service is doing so.

These can be included in commercial version. For a GPLed version, we just can NOT demand too much, especially for easiness features to use.
Anyway, command line mode is enough for us.

[rc_hz]

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.

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

Yes, it's also my problem about Ice! If some complete application of moderate complexity are presented, ICE will be easier to learn for many of us!

[naef_wy]

I tried to compiler the source files with intel c++ 8.0 compiler,there were many errors as"error #69" and others,I tried to modify the source,but it's too many,i gave up.So i want to know if a version which supported intel c++ 8.0 of win32 will be published.Thanks in advance.
wyan

[stevekr]

Is it possible to have a IDL to Slice (or WSDL to Slice), that wipe out features that are not handled (or not handled the same way) in both context.
It would be nice that the client can access a Webservice, an ORB and an Ice object with the same definition langage.

Is is possible to use ICE inside an Osgi framework ?
This may permit to use something else than webservice for communication in OSGi (www.osgi.org).

Thank you for your feedback.

[miaolin]

Borland C++ compiler support wantted!

[bernard]

At this time, we have no plan to support any non-Microsoft C++ compiler on Windows.

Best regards,
Bernard

[JohnB]

How about thread priorities?

We are contemplating using Ice on a Real-Time OS such as Qnx or LynxOS so we will need to use thread priorities. Maybe need to create a thread attributes object that can be passed to an overloaded IceUtil::Thread::Thread() constructor. Haven't thought this through much yet so it needs a lot of thought.

Maybe something like this:
class ThreadAttributes {...}

Priority inheritance for mutexes is not on by default on some Real-Time OS's so Ice Mutex should also enable this either automatically or via a constructor argument.

-john

[steu]

Hi, Ice is great! very good work!
I have a question: maybe possibile and not too difficult to implement a GSSAPI module for secure interoperability between client and servers?

[marc]

Originally Posted by steu

Hi, Ice is great! very good work!
I have a question: maybe possibile and not too difficult to implement a GSSAPI module for secure interoperability between client and servers?

Most likely this is possible, but it's not on our todo list due to the lack of (commercial) demand for such a feature.

[SteveWampler]

Hi folks,

One thing that we'd find very useful is the ability to scale IceStorm (I *think* this
is different than federating IceStorm...). That is, it would be nice to be able to
create multiple, distributed IceStorm servers that are 'delegates' of a central event
server registry. A client would connect to the registry and be given a handle
to one of the delegates. This delegation would be on the basis of the (sorry,
CORBA-term coming up) "ChannelName", not the client - so all posters and
subscribers to the same channel would be allocated to the same delegate,
automatically. Adding more delegates would allow the system to scale.

A clever registry would be able to do load-balancing, but a simple round-robin
approach would be nice to start. We have (in design) a highly distributed
telescope control system that relies heavily on events. A previous CORBA-based
system (different telescope) has a severe bottleneck in the centralized notification
service - we'd like to avoid that in this (bigger, faster) project.

Anyway, thanks for considering this - ICE is Nice (sorry).

[marc]

Are you talking about the telescope as described in this paper:

http://atst.nso.edu/library/spie/5496-40.pdf

If so, a very cool project, it's great to hear that you chose Ice for this If you would like to discuss a closer collaboration, please feel free to contact us at info@zeroc.com.

[SteveWampler]

That's the one. It is a interesting beast...

[Nis Baggesen]

When a slice interface definition is translated into C++ we get amongst other things a nice abstract Ice::Object class with all the defined methods as abstract functions.

This is all well and good, but in some cases it would be nice to simply have a pure language specific version of the interface. Something that wasn't an Ice::Object.

This would be useful for making delegate objects or for combining the ice system with other third party classes that one may not want to put directly into the adapter or other parts of the reference counting framework

[Nis Baggesen]

Being able to control the specific c++ typemapping (within the std framework possibly) with slice metatags would be nice

[DeepDiver]

Originally Posted by Nis Baggesen

Being able to control the specific c++ typemapping (within the std framework possibly) with slice metatags would be nice

Thats what we'd like to have as well!

the ObjectFactory could be used for this with a method like this:

virtual ::Ice::ObjectPtr create(const ::std::string&, const BasicStream& is) = 0;

so within the object factory the developer not just only instanciates a new object, he also takes care about the unmarshalling from the stream.

and within the slice meta tags we could tell the slice compiler what type shall be used:

["cpp:MyOwnFoo"]
class Foo
{
};

just an idea

cu tom