Archived

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

What feature would you like to see most in Ice?

124678

Comments

  • 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!
  • Looking for the src for the intel c++ compiler 8.0 under win32

    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
  • IDL WSDL and OSGi

    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.
  • Borland C++ compiler support wantted!

    Borland C++ compiler support wantted!
  • bernard
    bernard Jupiter, FL
    Intel C++/Borland C++ support on Windows

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

    Best regards,
    Bernard
  • 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
  • Gssapi

    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
    marc Florida
    steu wrote:
    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.
  • Scaling IceStorm...

    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
    marc Florida
    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.
  • That's the one. It is a interesting beast...
  • Simple language specific interfaces

    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
  • Slice metadata tags for c++ types

    Being able to control the specific c++ typemapping (within the std framework possibly) with slice metatags would be nice
  • 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
  • First of all I would like to expres my thanks to you guys for greating this wonderfull framework.
    I'm considering using Ice in my private project so I would like to know are there some bindings between Ice event loop and for example Qt or GTK event loop. Also if I'm considering to use some networking wrapper library like ACE are there some bindings between ACE reactor or proactor frameworks and Ice. Otherwise how it should be done if there are no the proper bindings.

    Thanks
    /Todor
  • marc
    marc Florida
    First of all I would like to expres my thanks to you guys for greating this wonderfull framework.
    I'm considering using Ice in my private project so I would like to know are there some bindings between Ice event loop and for example Qt or GTK event loop. Also if I'm considering to use some networking wrapper library like ACE are there some bindings between ACE reactor or proactor frameworks and Ice. Otherwise how it should be done if there are no the proper bindings.

    Thanks
    /Todor

    Ice does not have an event loop; it uses a thread pool model (or thread per connection). This means that integration with existing event loops is neither possible nor necessary. You just have to make sure that your application is thread safe.
  • With the newfound popularity of Ruby, especially in combination with the Rails framework, ICE support would be wonderful. Having to use webservices to access back end functionality is distressing.
  • marc
    marc Florida
    jrimmer wrote:
    With the newfound popularity of Ruby, especially in combination with the Rails framework, ICE support would be wonderful. Having to use webservices to access back end functionality is distressing.

    I looked at Ruby some time ago, and liked it very much. However, at this time it didn't have native threads, which made it unusable for Ice. Does Ruby have native thread support now?
  • Nope, Ruby's still missing native threads. As I'm interested in using Ruby as a caller and a native implementation won't be forthcoming how should I pursue integration? Wrap highlevel native C++ with a Ruby interface? Do you have a link for information on how to integrate non-supported runtime envrinments?

    Ruby v2, which will start trickling out later this year apparently contains support for native threading. Though as Ruby's an open source codebase who knows when it will be released or precisely what features it will contain.
  • marc
    marc Florida
    jrimmer wrote:
    Nope, Ruby's still missing native threads. As I'm interested in using Ruby as a caller and a native implementation won't be forthcoming how should I pursue integration? Wrap highlevel native C++ with a Ruby interface? Do you have a link for information on how to integrate non-supported runtime envrinments?

    If you only need client-side functionality, you could wrap C++ proxies in Ruby. For server-side integration, I'm afraid you are out of luck, as the C++ runtime will dispatch requests in native threads.

    You could look at the Ice for PHP source code for examples. Ice for PHP also has only client-side integration.

    (If you have further questions regarding this subject, please start a new thread. This thread is for a general discussion about new Ice features.)
  • Slightly off thread .... this is more about what I'd like to see on the Ice Web site and in Connections.

    What about doing some success stories or features on your clients and users. I would like to know how Ice has been used in application in the commercial and research world. There might be some wierd and interesting uses, approaches and tricks that we could all learn from .... a sort of knowledge database! Maybe some of this will trickle down to more advanced examples being included.

    Many thanks for the excellent documentation .... and clean, easy to read code.
  • why not support Delphi?

    I believe ICE is better than CORBA. And I am wondering why ICE does not support Delphi ,as we prefer to build client side with Delphi.

    Since ICE has been mapped to VB, why not Delphi?
  • marc
    marc Florida
    Doing a language mapping is a lot of work, and our priorities are driven by the needs of commercial customers. While many users expressed interest in Ice for Delphi on this message board in general, so far nobody had any commercial interest in such a product. In case you have a commercial need for Ice for Delphi, please contact us at info@zeroc.com.
  • Small Enhancement Request

    Hi,

    This isn't a big deal, but I would like to see a way to get the remote/local address without parsing the result of Connection::toString().

    Thanks,

    -- Andrew Bell
    andrew.bell.ia@gmail.com
  • marc
    marc Florida
    acbell wrote:
    This isn't a big deal, but I would like to see a way to get the remote/local address without parsing the result of Connection::toString().

    I agree. This is already on our todo list. (But I can't give you any release date for this feature yet.)
  • What about a shared memory Endpoint. I noticed Ice already has UdpEndpoint and TcpEndpoint. Would it be possible to create a shared memory version that bypasses the networking layer completetly?

    Given that how about making the optimization at a higher level? Ice already has a local invoke optimization wereby if client and server are in the same ObjectAdapter the runtime will "bypass much of the overhead of call dispatch" as the manual says.

    Could the shared memory optimization be made at this level too? That is can it avoid the marshaling step? Come to think of it does the local invoke even avoid marshaling. The data marshaling is done very early in the generated stubs.

    Thanks,
  • marc
    marc Florida
    As you write, a shared memory transport would only make sense if we would avoid marshaling altogether, otherwise there would only be little performance gain.

    However, this would be quite an intrusive change. In essence, it would be a completely different protocol, with completely different stubs and skeletons. It could not be implemented as a transport plug-in like UDP or SSL, as these work underneath the Ice protocol engine, which requires data encoding (marshaling).

    While this is doable in theory, it's rather unlikely that we implement this, as the performance gains are limited to interprocess communications on a single machine. Having said this, if you have a commercial need for such a transport, please feel free to contact us at info@zeroc.com :)

    The collocation optimization bypasses marshaling completely. But it's quite different from a shared memory transport, because the collocation optimization does not use any data buffering; instead, it uses direct invocations from the proxy on the skeleton, which can only work if client and server are linked together in the same process.
  • Support for CBuilder.
  • Provide delay-time invocations

    ICE now have twoway,oneway,batch,timeout invocations.But how can I make a delay invocation? Just like this:
    some_proxy->delay(50);
    some_proxy->some_operation();
    The operation return immediately,but the call will be sent to server by ice runtime 50 milliseconds later.
  • Hmmm... Can you explain what you would want this feature for? It's not clear to me why this would be useful.

    Cheers,

    Michi.