[e-lang] [RFP] cross-language object serialization (E <--->
rwithers12 at attbi.com
Tue Jan 21 06:52:17 UTC 2003
On Monday, January 20, 2003, at 09:33 PM, Mark S. Miller wrote:
> But in any case, based on the current state of the discussion, I think
> last non-WOS contender has been eliminated. Until and unless a
> problem shows up, I'm willing to declare that the next CapTP will use
> WOS as
> its serialization format, in both its doc-code-binary and its
> forms. Given this, I think that CapTP, like WOMP, should use Doc to
> its message layer as well. A CapTP connection should start in
> mode, and we need to define some textual negotiation for switching to
> doc-code binary format. How does WOMP deal with this format
> negotiation issue?
I still have some reservations, mainly in the area of what the
(primitive) type mapping looks like on the squeak side. On the whole I
agree that this will work and I am for it, if only to move forward with
a decision. I feel like we have made good progress.
Basically, we are saying that we want XML to define the types, and a
way to encode with that type definition in both text and binary. This
is all great. Now it's a question of whether the type definition
schema and the predefined primitive types and the binary encodings are
suitable to the squeak environment. I believe that the SAX-like driven
state machine is fine, although I am no expect at XML. I start to have
a little concern over the complexity of the schema, the predefined
types and the Charset based encodings. I need to look deeper.
So for now, here is my recommendation for the CapTP negotiation
protocol. It should *not* be Doc-XML-text, but rather a mimic of the
way ReplyInfo, Go and GoToo work. let us call them
EncodingConfirmed(code=3). They should use Utf encoding for strings.
We come up with a basic set of serialization names: 'JavaSerialized',
'SqueakSerialized', 'WosSerialized-XML', 'WosSerialized-Binary'. We
should also be able to pass properties during the Selected and
Confirmed queries just in case we need them for one of the encodings.
This will allow us to evolve.
Concerns with WOS
[WOS primitive type definitions]
I have just started looking, but there are a lot of primitive types
and they may not map so cleanly to squeak. Some of them look like
implementations, rather than types, and this could be difficult for
squeak. For instance the redblacktree. I would expect the
primitive types to match the principle language that the specifier
used. If I did it, you would have SortedCollection, OrderedCollection,
Fraction, Dictionary, and nil. I don't know what to do with Replace or
I'd expect a static set of primitive types, or predefined types, that
all languages could easily map to and from.
the schema is quite complex. Rather than relying on the schema name to
imply that the type is hashed, and thus let the language binding handle
that, this information is encoded into the schema Node. this makes it
tougher on the Encoder/Decoder implementor, rather than deferring it to
the language binding...and the language binding is still equally
complex. What is it's advantage?
I like Constantne's suggestion to use qualified names ala
caps.primitive.Integer, rather than file: urls.
[license] I must be able to release under the SqueakL
[Blocks] how are we going to pass blocks of code around? a litmus
test, but we weren't trying to solve it yet.
More information about the Squeak-dev