What feature would you like to see most in Ice?

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

[jhunt]

Support for CORBA.

;^)

[Jeff Holle]

I know that one of ICE user has done a python interface via boost.python, but don't know if this effort is finished or available to the ICE community.

With boost.python, this seems like an easy thing to do, and it would be a pitty if it isn't officially supported until things like C#.

[marc]

Originally posted by jhunt
Support for CORBA.

;^)

You need to be more specific

What kind of integration with CORBA do you have in mind? The type systems are different, which makes a general-purpose-integration difficult. On the other hand, some limited integration might be possible.

[marc]

Originally posted by Jeff Holle
I know that one of ICE user has done a python interface via boost.python, but don't know if this effort is finished or available to the ICE community.

With boost.python, this seems like an easy thing to do, and it would be a pitty if it isn't officially supported until things like C#.

Can you give me more pointers for boost.python? Is this some kind of integration between the C++ boost library and python?

[iostream]

Originally posted by marc
Can you give me more pointers for boost.python? Is this some kind of integration between the C++ boost library and python?

Boost.Python

From that page:

Welcome to version 2 of Boost.Python, a C++ library which enables seamless interoperability between C++ and the Python programming language.

Pretty cool stuff.

[Jeff Holle]

The best way to describe boost.python is providing this link:
http://www.boost.org/libs/python/doc/index.html

As to it relates to ICE, it would be used to produce a python extension module that provides an interface between the code produced by slice2cpp.

It could be incorperated into slice2cpp, via an optional command line parameter if desired. It surely would utilize a large part of the code of this utility.

Boost.python, like the rest of Boost, heavily uses templates and is portable to both unix environments and windows.

[vukicevic]

Python's a pretty bad fit for ICE, as I discovered.. Python is essentially single-threaded, while ICE is by nature multithreaded. Getting the locking right between threads, and getting boost:ython into the mix with the correct locking is a nightmare (multithreaded stuff with boost:ython is something that's not implemented atm, afaik.. I tried, and got part of the way there, but not enough to avoid deadlock in complex situations). I suppose a client-side-only implementation would be possible (similar to ICE for php), but I wouldn't think that's all that interesting for the majority of uses where python would make sense.

My spare hacking time has taken a drastic hit in the past few months, so I haven't had much time to work on my own C# implementation, so I'd personally love to see ICE for C#, implemented natively in C# and supported by ZeroC

[michi]

Originally posted by vukicevic
My spare hacking time has taken a drastic hit in the past few months, so I haven't had much time to work on my own C# implementation, so I'd personally love to see ICE for C#, implemented natively in C# and supported by ZeroC

I'm working on that. Stay tuned -- sometime early next year we should be able to oblige

Cheers,

Michi.

[dwforslund]

There CORBA area I would like to see is translating (at least partially) IDL into ICE. How about a UML Profile for ICE

The other area is WebServices integration to ICE. The idea is to be able to deploy an ICE application through WebServices in a fairly automatic manner.

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

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

[kssreeram]

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

ICE shoudl support thousands of connections out of the box. I am not sure using 'select()' on win32 is the most effecient implementation when setting FD_SETSIZE to 1000+.

There may be a more effecient win32 specific implementation possible.

[marc]

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.

ICE shoudl support thousands of connections out of the box. I am not sure using 'select()' on win32 is the most effecient implementation when setting FD_SETSIZE to 1000+.

There may be a more effecient win32 specific implementation possible.

This is a trivial change, we only have to change one #define in a header.

The other windows calls (WaitForMultipleObjects) have the same small default limits as select(). select() is not less efficient than WaitForMultipleObjects(), even with large FD_SETSIZEs, because of the way our thread pool handles select() in the WIN32 case. I.e., there are special optimizations in our thread pool for select() and WIN32 that makes it very efficient.

See also this thread regarding this topic.

[amrufon]

VB Support without coding in C++ or Java.

Ok. Before everybody jumps on me let me explain where I'm coming from. I work for a Supply-chain integration software development company. In our Philippines office, there are around 100+ programmers working on different projects. The skill distribution are:
ASP - 80%
VB - 100%
Java - 3%
C++ - 1% <--- its me and I'm a junior manager level (which means I hardly code)

A few weeks back, I reviewed a project proposal by another group and I realized that the project would benefit if it uses ICE. So I scheduled a meeting with the thier project manager and technical team leader and gave them an introduction to ICE. I did a demo and a cost benefit analysis for thier project.

The thing is, they were both impressed. They both agreed that it would benefit thier project. Unfortunately because of economic issues, lack of time and resources ... they didn't adopt ICE and are developing inter-product communication through the use of EDI documents sent through FTP. This is sad because if they use ICE, updating the purchase order would only require to build an ICE interface and use it unlike now they have to (1) create an EDI document, (2) upload it to FTP, (3) make a program which polls the FTP, (4) read the EDI document and (5) verify if it valid, (6) translate it into the proper format and (7) update the purchase order.

So my suggestion is a version of ICE wherein it can be included into a VB DLL and events be handled. Something similar to the current development pipeline where we create a SLICE definition, create a server to handle requests and create clients to send the request. The difference is that there is no C++ or Java programming. The declared methods are received by ICE and the appropriate VB DLL method that is bind to it is invoked.

Just an idea.

Alex