On Tuesday, January 21, 2003, at 02:54 AM, Mark S. Miller wrote:
>
>> 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.
>
> Mimic what? I'm ignorant of the system you refer to.

Shoot, I did it again!  :)   I was talking about negotiation states in 
VatTP.  ReplyInfo provides a list of possible choices, Go selects one, 
and GoToo acknowledges that selection.

I actually think that this should be negotiated in VatTP, before the 
CapTP layer gett's ahold of it.  All the coordination that was used 
during negotiation doesn't exist in CapTP (call vs answer modes).


> We should distinguish negotiations whose choices are semantically
> significant (Java Serialization vs WOS) from negotiating semantics-free
> encodings (WOS/XML vs WOS/doc-code). We should postpone thinking about 
> the
> first because it's hard ;). All we currently need is the second.

All I am saying is that we need the opportunity to select yet another 
choice.  i don't want to have to do that negotiation in another format 
that the other plain-text negotiation has occurred in.



>
> I agree, but I took these, perhaps mistakenly, not as types mandated by
> WOS, but just types defined by waterken.com as one of the users of WOS.
> Tyler, did I misunderstand? Many of these would be as problematic for 
> E as
> for Squeak.
>
> But we do need an agreed upon set of mandated primitive types. We 
> should
> start as small as possible, but I think that'll probably still be 
> moderately
> big.

Ok, this was my main concern with WOS



>
> The point of XML is to be compatible with a runaway bandwagon. 
> However, I
> don't know the sensibilities of this bandwagon, and the standards text 
> is
> only weak evidence about these sensibilities. E names
> behavior/object-layouts (ie, representation "types") with Java-like 
> fully
> qualified names.  Assuming Tyler and Sue are right about the
> sensibilities of XMLers, I'm willing to mangle these into file: urls.
>
> But I would like to hear other opinions about the sensibilities of 
> XMLers on
> such matters. I'd rather not do something obtuse and hard to read only 
> in
> order to be compatible with standards text recommendations no one 
> listens to.

hmm.

>
>> [license]  I must be able to release under the SqueakL
>
> WHY??? Due to an unfortunate technicality, SqueakL is not open-source. 
> I
> STRONGLY recommend using an open source license that's link-compatible 
> with
> both SqueakL and Mozilla. PLEASE.

this one's on a different thread now!  ;-)   Hopefully one or two more 
squeakers will speak up, but by this point I am kinda doubtful.


>
>> [Blocks]  how are we going to pass blocks of code around?  a litmus 
>> test,
>> but we weren't trying to solve it yet.
>
> Smalltalk blocks-closures? Forget it, it's hopeless. You'd need to 
> first add
> the equivalent of a PassByCopy auditor.
>


Well at least you have a way and we have a way...that's good enough for 
now on that particular item

cheers,
rob