What feature would you like to see most in Ice?

The next major release of Ice will provide for Ice for C# with SSL.

Cheers,

Michi.

Although it is not feauture of Ice itself it would be nice to have syntax support of slice in editors like emacs/xemacs, slickedit etc. Or you can let people upload their versions of such configs on your website for others to use.

vim has a syntax highlighting module for Slice. See http://www.zeroc.com/vbulletin/showthread.php?t=818

Cheers,

Michi.

Emacs slice mode

I use emacs IDL mode with the gnu indentation mode. Works quite well. Perhaps this would be a good starting point for anyone interested in adding better syntax highlighting.

Regards

.NET 2.0 support

...this is the only thing I'm waiting for. The feature set you currently offer is complete for.

all waiting for C# 2.0 i guess

feature set is really alright:
* as i noticed u wanna provide custom performance counters -> great! need that!
would be nice to provide a "fitness" function for different QoS aspects. in my project: network latency/bandwith considerations of far distributed services and cpu utilization
but have no idea how?

* get rid of polymorphic limitation for methods-> forget languages that dont provide that

* consider those stupid localized windows versions (meaning some bugs in ICE and "c:\white spaces in path to config")

* config consolidation towards xml

* dont forget the internet OS *BSD: sould not be too hard to test for __FREEBSD__ macros where __APPLE__ is defined

* documentations toward an iterative development process. have problems to find a good way to patch, distribute and redeploy during development

skropp wrote:

* get rid of polymorphic limitation for methods-> forget languages that dont provide that

I'm not sure what you mean by that. Ice doesn't have any restrictions with respect to polymorphism. Or do you mean overloading functions with different signatures? This does not really have to do with polymorphism; it's more a convenience feature. The problem with supporting this is not just languages that do not support overloading functions. The main problem is that the Ice protocol would become quite ugly, because you would have to mangle the signature into the operation name.

IceStorm not centralized

marc wrote:

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.

Hi all!:
This is my sugestion:

I'd like IceStorm to be not centralize. I mean something like message oriented middleware but with Ice flavor. May be:

- installing an IceStorm per compouter communicating one each other via multicast.
- topics linked to multicast directions
- just the inside code would change; no changes in programs made by user.

Well, what do you think?

Regards

Tcl support for ICE

Is there any hope seeing tcl (Tcl/Tk) API for ICE Library ?

I agree with chcases
I would like IceStorm to be distributed 1.e multiple Ice Strom servers
connected with each other so that they become fault tolerance / replication

-- Ice strom servers running in diffrent machines.
-- they replicate subcriptions automatically
-- Publishers can publish in any one IceStrom server
-- Subcriber to subcribe any IceStrom and recive event from there
see spread tool kit www.spread.org
~Anand

Add a command option to slice2cpp for generating reflection codes to improve C++ programming with ICE.

Slice support for Doxygen would be nice...

Qt Mappings

Sorry, should've posted this ages ago!

A version of slice2cpp to generate C++ mappings using Qt types would be very nice and potentially quite simple (as Qt provides conversions to and from stdlib types). In fact, if this is not too difficult I may consider implementing it myself when I have more time

MinGW Build Support

Continuing from previous post, Qt for Windows uses MinGW so support for that would also be very nice

I have already attempted to compile ICE in MinGW but there were a few problems and I have been busy on other things. I will try again as soon as time permits!

Support for JMS

Hey there;

I work as a systems engineer at a bank down Wall Street and I am a newbie to ICE. First, may I say congratulations! I have been playing with the example programs and I have been very impressed with all that ICE has to offer.

It would be nice if there was a java library that supports the JMS interface but uses ICE on the backend. This would be very attractive to many products which have a significant java code base using JMS but whom are unhappy with the performance scalability and stability of the middleware systems. It would be a no brainer to show the management of these products the performance numbers ICE brings to the table and then offer them an uprade strategy that has one middleware system being replaced with ICE, without having to rewrite the java code that is already there.

Just a suggestion. Once again guys, I love ICE and I continue to promote it whenever and wherever I can. Thanks!

PS. Another suggestion, devote a webpage or pdf to just sample code. The manual is very well written but not something I want to lug on the number 6 train home in the evening. Maybe something along the lines of the Cookbook series from O'Reilly?

John

jschreud wrote:

PS. Another suggestion, devote a webpage or pdf to just sample code. The manual is very well written but not something I want to lug on the number 6 train home in the evening. Maybe something along the lines of the Cookbook series from O'Reilly?

Did you have a look at our newsletter? Our newsletter has many examples, covering various Ice topics.

Oh, I forgot about the newsletters. Yes, those are extremely helpful! I especially liked the article on integrating ICE into a multithreaded GUI app. I guess what I was talking about is taking the newsletter, drop the news part and put the code somewhere folks can easily search for it. A good example I can think of is what Syncfusion (www.syncfusion.com) did on their support site. Syncfusion makes .NET GUI widgets and confused folks such as myself can go to the support page and search the knowledge base for FAQ's. I dunno, I think it could really help you guys as a first line of support.

John

C# .Net 2.0

A nice feature would be support for .net 2.0 in the latest release.

Do you guys have any tentative dates for support c# on vs2005?

.NET 2.0 support

The next Ice release will support .NET 2.0. It's already working on our mainline. However, we did not announce a date for this release yet.

Cheers,
Bernard

I have a small suggestions for icegridadmin command tool
you can add a option for server restart instead of stopt start.

What I would like to see is if a property is set or not... Right now it's not possible to have like
"if property 'Cat.House' is not set -> Take 'Animal.House'". This is OK for as long as Cat.House is not empty. Then you can say like 'ok, take the animal house'. But what if it is intentionally empty? Then it will take the animal house, but that's a wrong behaviour...

My opinion would be to add "bool isPropertySet( string prop )" to the Properties object.


Greetings,
Steven

Something else what would be interesting is for example: RWRecMutex::RWLock in such a way that when you initiate it, it is a RLock, but you can upgrade() it to a WLock...

RWRecMutex has an upgrade() method that allows you to do just that. See page 679 in the manual.

Cheers,

Michi.

I know, but I'm using the RLock/WLock typdefs... Which has not this function (afaik).

So I made a RWLock:

class RWLock
{
public:
  RWLock(IceUtil::RWRecMutex& _mutex)
  : m_mutex(_mutex),
    rlock(_mutex) // automatically readlocking...
  {
  }

  ~RWLock()
  {
  }

  void upgrade()
  {
    m_mutex.upgrade();
  }

  void downgrade( )
  {
    m_mutex.downgrade();
  }

private:
  IceUtil::RWRecMutex& m_mutex;
  IceUtil::RWRecMutex::RLock rlock;

  RWLock();
  RWLock(const RWLock&);
  RWLock& operator=(const RWLock&);
};

But it would be nice to see it native in ICE

I'm not sure I understand what you mean. If you have a RWRecMutex and you use the RLock typedef, you can still upgrade:

RWRecMutex m;

// ...

RWRecMutex::RLock lock(m);

// m is now locked for reading.
// ...

m.upgrade();

// M is now locked for writing.

Cheers,

Michi.

OMG!!!! so easy I forgot that!

Reliable UDP?

Question: is there any reason why we couldnt envisage implementing a reliable UDP protocol?

The advantage of reliable UDP wrt TCP is that there is no requirement for packets to be received in sequence, so a single lost packet wont delay the packets that go after it.

One way to implement this could be to use http://www.lidgren.net/wiki/doku.php?id=lidgren.library.network

Hugh Perkins
OpenSource Metaverse Project http://metaverse.sourceforge.net

There is no reason not to implement a reliable UDP transport protocol, but Ice is not the right abstraction level for this. Ice uses existing transport protocols (TCP, UDP, SSL), but doesn't try to add new transport protocols.

Marc,

Yes you are right. As you say implementing a new transport layer within ICE itself would not be a Good Thing.

How easy would it be to add a new transport layer as a plugin, ie without recompiling the ICE library itself?

Yes, you can write a transport plug-in without recompiling the core library. Writing a transport plug-in is certainly no trivial task, but it's not rocket science either. You could look at the SSL plug-in for an example.