My first critic

Re: My first critic

Originally posted by Martin.Both
I just read your documentation. It looks very interesting.
Here my first comments:

1. Fixed-point type
The slice language is well designed.
I miss a Fixed-point decimal type.
It is a mistake using strings to represent fixed-point
values.

We debated whether to add a fixed-point type or not. In the end, we decided against it. The reasoning: fixed-point types are not required by the bulk of application developers. (This judgement is based on our experience with ORBacus; of course, that is small consolation if you are one of those developers who really need it ;-) In addition, languages that actually do support a native fixed-point type also provide conversion routines to convert fixed-point values to/from strings. This means that, if you really need a fixed-point type, you can easily use it from, say, COBOL (assuming that there is a COBOL language binding, which is another issue entirely). If you need to deal with fixed-point types in a language that doesn't support them natively, such as C++, you will most likely be using a library that emulates a fixed-point type (including conversion to/from string), so transmitting fixed-point types as strings isn't that much of a hardship.

Having said all that, I admit that having a fixed-point type as a native data type in Slice would improve static type safety. We considered that and, in the end, decided that, in the interest of simplicity, it was better to not add a fixed-point type to Slice. If you are one of those developers who desperately need a fixed-point type, you will disagree with this decision (understandably so) but, on balance, not enough people really need the type to make the added complexity worthwhile.

2. Protocol
I wondering if your network protocol supports fragmented
messages. I did nothing found about the protocol definition
in your documentation. It is a very useful feature of IIOP to have
fragmented messages. Using fragments a thread cannot block
one connection with a large message.

No, fragmented messages are not supported. Again, we considered this and decided against it. Reasons: Ice is natively threaded, so the only time you will find the receiver blocking is if the receiver has run out of threads or if the receiver has run out of memory. If the former, fragmenting messages won't fix the problem because it takes only one extra request (even with fragmentation) to cause the very same problem. If the latter, the receiver is in big trouble anyway, fragmentation or not. In essence, the IIOP fragmentation was an artificial construct that (to the best of my knowledge) was only ever implemented by IONA. The idea is that, for the server side, fragmentation (marginally) reduces memory requirements during marshaling. In theory, that's a worthwhile goal; in practice, it doesn't really work. The reason is that, even though the server is less burdened, the client doesn't get any advantage whatsoever because of fragmentation -- the memory requirements on the client side are exactly the same. If you look through the OMG defect archives, you will find that fragmentation has added an entirely unexpected level complexity to an already complex protocol, for at best marginal gain. Overall, we felt that not supporting fragmentation was the best engineering trade-off.

3. RealTime
Your timeout settings look very simple. You don't address
realtime applications, don't you.

Correct. Ice is "real fast" but not "real time". Bulding a real-time distributed infrastructure is an entirely different ball game. Fundamentally, Ice could be adapted to such enviroments, but we haven't made any moves in that direction yet -- the real time market is too specialized for us to focus our effort in that direction at the moment.

4. ObjectByValue/Reference
You mention that CORBA value type supports only pass-by-value
semantics. That is not true. CORBA abstract interfaces supporting
both pass-by-value and pass-by-reference semantic but your
design is easier to understand.

Thanks! Actually, you can have a proxy to a class instance just as you can have a CORBA object reference to an OBV instance. Via the proxy, you can invoke operations on the instance and any such operation invocations will actually be sent to the remote end, just as for a proxy to an interface. On the other hand, invocations sent via a smart pointer (or Java reference) to a class instance are always local invocations. Personally, I'm hard pressed to find a use case that would justify having a both a proxy and a smart pointer to the same (conceptual) class instance because invocations via the proxy go remote, but invocations via the smart pointer stay local. Architecturally, there is no reason to prohibit these semantics; pragmatically, I honestly don't know what they would be useful for.

I wish that future CORBA versions will partly break backward
compatibility and go in your direction.

Unlikely, in my opinion. This is as much a political as a technical problem. Technically, CORBA is not very adaptable to change. A number of architectural decision were (unwittingly) made more than ten years ago that make it technically infeasible to fix some of CORBA's problems. Case in point: CDR encapsulations to not have a separate version number. In practice, this means that there is no way for the receiver of a CORBA request to detect whether it is being presented with marshaled data that it cannot possibly decode. (All it takes is for a CORBA Any value to cross CORBA version boundaries during transmission, as often happens with the CORBA event service.) There are many other similar architectural decision that make it difficult to evolve CORBA beyond its current limitations.

Politically, the OMG is a strange organization. Having been deeply involved in the OMG for quite a few years myself, both as a chair of several task forces and as an Architecture Board member, I have learned that most decisions made in the OMG are based on political and marketing considerations much more so than on technical merit. The reality of the situtation is that, if a particular change does not suit one of the major OMG members, the change simply will not happen. Case in point: the horribly broken codeset negotiation scheme. At OOC, we tried to make this thing work for several years, but we never entirely succeeded. The specification for codeset negotiation is flawed not only in technical detail, but also in its fundamental design. When you step back and think about it, there is absolutely no need of all this complex machinery (which doesn't work anyway): just use Unicode and be done with it. By doing that, the entire problem goes up in a cloud of smoke. Why aren't the OMG doing it then? Because Fujitsu, due to commercial interests, have persistently blocked any move toward a better technical solution to supporting wide characters and strings. This particular example is just one of many -- politics at work...

Cheers,

Michi.

Originally posted by Martin.Both

[...]
What I miss is a description of your connection management
in this case and the protocol definition.

Writing a chapter about the Ice protocol is on our todo list

BTW, the Ice protocol is of course versioned, so should we decide some day to add fragmentation, we could certainly do this. It's a tradeoff features vs. complexity. So far, we didn't consider this feature important.

Another possibility would be to solve this at the transport level: Create a TCP/IP-based transport plug-in that is capable of sending messages in fragments. I think this would be simpler & cleaner: The Ice protocol would stay the same, but the specialized transport would fragment messages.