Archived

This forum has been archived. Please start a new discussion on GitHub.

What feature would you like to see most in Ice?

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.
«1345678

Comments

  • Support for CORBA.

    ;^)
  • Support for python

    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#.
  • 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.
  • Re: Support for python
    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?
  • Re: Re: Support for python
    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.
  • 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.
  • 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::python into the mix with the correct locking is a nightmare (multithreaded stuff with boost::python 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 :)
  • 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.
  • 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.
  • RE: What feature would you like to see most in Ice?

    i 'd like see a light ICE for mobile phones, and PDA :p , and , could be interesting that Ice probides a simple SOAP iface?. :confused:
  • Server-To-Client Callbacks Thru Client Initiated Connections

    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.
  • Better Networking on Win32

    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.
  • Re: Better Networking on Win32
    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.
  • VB Support

    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
  • Support 4 Delphi & Kylix

    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
  • More CCM-like

    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.
  • 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
  • Re: Better Networking on Win32
    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.
  • Re: Server-To-Client Callbacks Thru Client Initiated Connections
    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
    xdm La Coruña, Spain
    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
  • Event filtering in IceStorm.

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

    Stronger CCM support (echoing another user's comment...)
  • 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.
  • 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
    edited April 2019
    DII

    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 www.cuj.com/documents/s=8943/cujexp0312vinoski/ (broken link) 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
    marc Florida
    edited April 2019
    Re: DII
    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 www.cuj.com/documents/s=8943/cujexp0312vinoski/ (broken link) 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.
  • Re: Re: DII
    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.
  • 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
  • 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).
  • 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.
  • Re: RE: What feature would you like to see most in Ice?
    Originally posted by salva
    i 'd like see a light ICE for mobile phones, and PDA :p , and , could be interesting that Ice probides a simple SOAP iface?. :confused:

    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.