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 
> the
> last non-WOS contender has been eliminated. Until and unless a 
> surprising
> 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 
> XML-textual
> forms. Given this, I think that CapTP, like WOMP, should use Doc to 
> define
> its message layer as well. A CapTP connection should start in 
> Doc-XML-text
> 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 
EncodingsOffered(code=1), EncodingSelected(code=2), 
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 
Multi.

I'd expect a static set of primitive types, or predefined types, that 
all languages could easily map to and from.

[schema]
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?

[schema naming]
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.


cheers,
robert