[ChMeessen]

Hello,

I have also been working on designing an O2O infrastructure and also attempt to address many shortcommings of CORBA.

Your protocol is much simpler and efficient than what I came up with. Though I am still hesitant about fixed endianess and forbidding method overloading. But you also have good reason to do so.

There are two major features I designed in my O2O system for which I don't see an equivalent in ICE.

On is the object referencing model and the other is security.

For the referencing model, Ice use a locator based on object naming. For an Internet wide application involving zillions of objects, I guess you would use composed naming as for the dns.

In my system a reference is a simple integer. Its the most compact, ensure uniqueness and location independency.

Named object access uses a specific directory service where an entry can hold the reference of an object or another directory with additional informations like a URL, icon, dates, ... Thus I make a clear functional separation between the locator service and the directory service.


For the security, when working over Internet, one needs to be able to authenticate the client and provide support for access control down to servant and method calls if possible. SSL support provided by Ice address only partially the security needs.

Beside, x509 certificats to be used with SSL have as CORBA quite a long list of undesirable features. A secured underlying O2O infrastructure could help to solve many problems of x509. (revocation checking, useless certificate info, renewal frequency of certificats and especially root CA certificates, ... )

My impression after reading the documentation (not in detail though) is that these functionalities could be added to Ice with very few extensions to the API. (backward compatible).