Archived

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

What feature would you like to see most in Ice?

135678

Comments

  • for HTTP, maybe....
    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?....
  • The Ice must not bind 80 port direct !

    Usually, the web server is IIS or apache... etc
  • IPV6?

    HI,

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


    Thanks,
    Andrey.
  • marc
    marc Florida
    Supporting this is trivial. We do this as soon as IPv6 becomes relevant ;)
  • usage of autotools for configuration of the sources

    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 ;-)
  • Re: usage of autotools for configuration of the sources
    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;
  • 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 :)
  • 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.
  • integration with web service

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

    and, how to use slice2wsdl?
  • marc
    marc Florida
    Re: integration with web service
    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.
  • 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.
  • Add some protocols for better IPC performance!

    Provide more communication protocol options,such as:
    Unix Domain Socket,Shared Memory,etc.
  • i want to development of ice integrated develop tools!
  • marc
    marc Florida
    Re: Add some protocols for better IPC performance!
    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.
  • philip_lamb
    philip_lamb Christchurch, New Zealand
    Objective-C bindings (e.g. Mac OS X)

    Objective-C is (as I'm sure you know) a nice object-oriented language, and gets a lot of workout on the Mac OS X platform. So I and others would love to see ICE with Objective-C bindings.
  • About documentation

    Hello guys, I'm involved with a videogame project for our career graduation project, we were browsing through some network API's when we stumbled with ICE and fell in love with it. It's simple, easy and has a powerful set of features. Yet we don't know how to use them all, we are still reading the PDF manual.

    It has a nice manual, but I would really like to see a section or a new manual about programming videogames with it, some examples, just to get started, not programming a full one, stuff like deployment, patching, managing the gameloop in a distributed environment, etc., I don't know if all this stuff is covered on the current manual, I just would like to see videogame oriented examples.

    The reason for this is that I think videogames is a very profitable software trend that is growing very fast. So supporting it directly through documentation wouldn't be bad I think :D

    Well, I hope I communicated what was intended. See you later.


    P.D. Sorry for my english :P
  • Add getter/setter method for slice2java command

    I want to use the Hibernate ORM framework as the persistence mechanism for ICE slice. Hibernate require a java class must be a POJO,it calls java object's setters to set the members' value instead of assigning values to members directly. So I think add these getter/setters in slice2java automatic will be a graceful solution. Example:
    //slice Cat.ice
    class Cat {
    string name;
    int color;
    bool sex;
    float weight;
    };

    //Java Cat.java
    public class Cat extends Ice.ObjectImpl{
    ....
    public String name;
    public int color;
    public boolean sex;
    public float weight;
    public String getName(){
    return name;
    }
    public void setName(String name){
    this.name = name;
    }
    ....
    }

    I will be in appreciation of seeing new --getter and --setter option with slice2java in next ICE release.
    Thanks a lot.
  • Please provide a way to generate toString method in Java

    Hi,

    It would be nice to have toString generated automatically may be use of some metadata on the class/structure level.

    Thanks,
    --Venkat.
  • Encapsulate data as private members and provide getters and settters

    Hi,

    ICE being OO Middleware, it causes be some uneasiness to see code directly accessing data members (encapsulation) of a class. Please provide getters and setters and make the data members private.

    Thanks,
    --Venkat.
  • enhancing features to get the name of MIDDLEWARE

    there are too much MIDDLEWARE named thing. weblogic is bea MIDDLEWARE, 9i is elison MIDDLEWARE, EJB is open MIDDLEWARE, RMI is .net MIDDLEWARE, CICS is expensive MIDDLEWARE, HTTP is world wide MIDDLEWARE, biztalk is ms MIDDLEWARE, socket is first MIDDLEWARE, ss7 is telecommunication MIDDLEWARE,... most joking is ibm, her ad us that IBM is MIDDLE and IBMware is MIDDLEware.

    me come across so much MIDDLEWARE named thing, but me hate MIDDLEWARE. their frugging princleples and name that trapped most of the no-so-smart new man suffering, losing patience and confidence really slow down the "noneself control" programming level.

    ice is most nearly close to my ideal MIDDLEWARE! what is ur MIDDLEWARE concept? mine is that a programing languange level mechanism which provide source coder "noneself control" programming. here "noneself" means not myself, not this system, not this machine, not this bus, no this cpu.

    ice using a infrastructure of interface(server)-proxy(client) to support remote programming, which is the same as CORBA. sure me know u nearly have to designed yourware this kind, but if of transparence is better. the fellows:

    ASM:
    move ax &h90
    @192.168.0.1 move ax &90
    C:
    int aX = 90;
    int ax = 90 remote @192.168.0.1;
    C++:
    MyClass myInst;
    MyClass myInst stack@192.168.0.1;
    MyClass myInst heap@192.168.0.1;
    Basic:
    dim aXX = "90" as String
    pla aXX = "90" as String @192.168.0.1;

    me sure no team or no group can supporte this kind of programming transparence now, but me tried. with my rearch deep into inch earth, me feared, and in terror soon, at last, horror ar...

    me found, MIDDLEWARE is ugly, unreasonable and illlogic. static code in windows view or on paper drive us into a ether motif, an Albert will pointe us out that there is a max C dictate all??!!! me fait lar..

    ...

    when me come back, me just sure us need a MIDDLEWARE, as IBM need IBMware, no matter ugly or not, just a means of be. what me hope zeroC do is to make ice more like a MIDDLEWARE and try to sample these guys a MIDDLEWARE, then FUD anyelse to title his this name.
  • Re: an useful feature !!!
    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.


    xiaosiwolar:D :D:D:D
  • Guaranteed delivery

    ICE provides an at-most-once messaging delivery guarantee. Is there a plan to implement exactly-once (guaranteed) delivery- or perhaps you feel that this is better implemented at a different abstraction layer? Where/how (in general) would you implement it? At the moment it does not appear as though the lack would be a dealbreaker as far as implementing ICE as a middleware solution but I'd like to at least know if there's a good solution in case it comes up again.

    Matt
  • marc
    marc Florida
    Re: Guaranteed delivery
    Originally posted by griffima
    ICE provides an at-most-once messaging delivery guarantee. Is there a plan to implement exactly-once (guaranteed) delivery- or perhaps you feel that this is better implemented at a different abstraction layer? Where/how (in general) would you implement it? At the moment it does not appear as though the lack would be a dealbreaker as far as implementing ICE as a middleware solution but I'd like to at least know if there's a good solution in case it comes up again.

    Matt

    Can you clarify what you mean with guaranteed delivery? What should Ice do if there is a network failure, or if the server or client crashes? Do you want some kind of persistent message queue, that stores messages until the network connection is up again, or until a server or client is restarted after a crash?
  • Yes, I was referring to a persistant message queue.
  • marc
    marc Florida
    Originally posted by griffima
    Yes, I was referring to a persistant message queue.

    Usually this is done in connection with a messaging or event service, such as IceStorm. Making every invocation in the Ice core persistent would mean way too much overhead.

    Persistent messages for IceStorm is something we considered, but didn't implement yet, because so far there has been no commercial demand for such a feature.
  • For ICE for C#, many cannot afford a copy of M$ VS.net. But since .Net framework SDK is free, which include C# compiler and nmake. Why not supply makefiles for nmake, as well as VS project file.:confused:
  • I will try and add support for the free C# compiler to the build environment. No promises as to the date though!

    Cheers,

    Michi.
  • Originally posted by mep
    For ICE for C#, many cannot afford a copy of M$ VS.net. But since .Net framework SDK is free, which include C# compiler and nmake. Why not supply makefiles for nmake, as well as VS project file.:confused:

    Why don't you simply use SharpDevelop, which is also free, and convert the VS sln files into SharpDevelop projects? That works without any problems for the Ice project files!
  • 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.
  • 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.