Mark,
As the CORBA apologist, I just have to chime in... :-/
- By "platform neutral" I don't mean that it can't favor or be based on
one
platform (such as Squeak), but rather that it not impose a level of pain
on
other platforms significantly beyond what a truly neutral format would impose. For example, Java's RMI, despite all its faults, is a better "platform neutral" system than Corba.
I think our assumptions about "better" weight different factors...
While RMI is built to support Java specifically, it is less painful for other platforms than is Corba.
I'd appreciate references to experiments that demonstrate this. It could well be true. It is also worth noting that RMI is also lighter-weight and therefore less general than CORBA. Depending on system constraints, this will obviously favor one over the other.
Corba imposes similar pain on everyone, and that level of pain is higher for everyone. I'm more interested in standards which reduce the general level of pain than in ones which allocate pain "fairly".
I object to the use of the word "standard" in this context. I think you mean "platform" here.
A platform independent system, like Corba, is just covertly yet another platform,
Nothing covert - OMG has recognized CORBA as an independent platform at least since I started participating in 1996!
and usually one less well designed than the platforms it's trying to be independent of.
Of Java I would agree, too :-D At least CORBA is designed - Java is cobbled together under unreasonably tight deadlines, which leads to it being timely, but not necessarily well built. All (except timeliness) complaints that are often aimed at CORBA and MS as well.
The statement as spoken is true; however, as a long-time observer of the CORBA development process, I would claim that the implicit assertion that CORBA is (intentionally) less well-designed is untrue. I would agree that it may not be as effective as more recent equivalent protocols (RMI is NOT an equivalent protocol - merely similar). But this is due more to the fact that GIOP is older (~1993) and doesn't benefit from more recent research.
In general, I have the impression that you're not making a sufficient distinction between the run-time CORBA infrastructure (the ORB) - which isn't particularly relevant to this discussion - and the Common Data Representation used as the normalized format in CORBA message - which is VERY relevant to this discussion. Whether or not you choose it, I think that you should consider the CDR as a possible serialization format. More specifically, after looking at the requirements below, I think that you should consider CDR-encoded OMG Objects-by-Value (IDL valuetypes) as an option. The URL for this aspect of the CORBA spec is http://www.omg.org/cgi-bin/doc?formal/01-12-43
So don't be shy about proposing Squeak-based or Parcels-based
serialization
formats.
- From previous discussion on e-lang, I feel we must have both a textual
and binary serialization format, designed together, or one derived from
the
other, such that conversion in either direction is meaning preserving. A connection will start out textual, and will switch to binary only after a text-based negotiation about how to proceed. That way we enable text-only processors (humans on a telnet) to play.
With the possible exception of the telnet requirement, I think that valuetypes would support this, since there is the standard CDR encoding, as well as a valuetype-to-XML mapping specified :-)
- Both formats must provide good support for upgrade (or class
evolution).
Java serialization, for all its awful complexity, does this, and I'd like one that does at least this well. My understanding is that Parcels does
an
excellent job at upgrade, but I'm much less familiar with it.
If this is code evolution, then the valuetype spec has the concept of being able to identify the "codebase" for which the valuetype is designed. If the issue is state evolution, the valuetypes include inheritance semantics; therefore, they can evolve in a backwards compatable way.
- The textual format must be human readable and human editable. This
combined with the "meaning preserving in both directions" requirement
means
that one can edit a binary serialization graph by translating to text, editing, and translating back. Likewise, it enables a logger to log
binary
network traffic as binary, and then later present it as textual if there's interest. An edited textual log can then be used as a basis of test cases.
This is probably hard in the CDR case, but certainly would be possible in an XML marshalled message.
- The binary format must be able to perform reasonably. My understanding
is that Parcels is unmatched here on reading speed, but I have no idea
what
price it pays on writing. For CapTP's use, each graph will be written
once
in order to be read once. For persistence use, many more graphs will be written (one per checkpoint) than will be read (one per revival). Both of these are different than the tradeoffs Parcels was optimized for.
I'll admit that I can't speak to this.
- Both formats must be simple, and easy to document. Java serialization
fails this test.
The CDR format is well specified and straightforward. XML should be as easy as it ever is (opinions seem to vary in this forum).
- The format must be compatible with our security requirements. In
particular, since E is only prepared to trust mobile E code, any need for executable code in the serialization format must be E code. Parcels as is fails this test of course.
The valuetype serialization carries no code, but does provide a slot to identify downloadable code that implements the valuetype.
-DMC