Re: [disc] argument order to cords...

[Erik Ostrom <eostrom@research.att.com>]

> o	cords are a special case of MCP message with a fixed
> 	keyword/value order

No.  The use of the word "after" in the spec is incorrect.

> o	cords are a normal MCP message and the _message argument can
> 	appear anywhere in the message and should have a quoted string
> 	value if the _message is intended to contain several parameters
> 	which are to be passed to the cord's recipient.

No.  The _message argument is intended to contain a single identifier.
(This may be quoted, or not.)

> o	underscore keywords (_...) are special cased for cord messages
> 	and only non-underscore keywords are passed to the cord's recipient.

No.  It is up to the implementation how arguments are passed to "the cord's
recipient" (if there is a recipient).

In the implementations I've worked on, _id has mapped to an object, _message 
has mapped to a method on that object, and there have been at least three ways 
to pass arguments to that method:

  * The entire keyword-value mapping is passed to the method, and it can
    pull out what it wants.

  * Certain keyword arguments are expected; these are pulled out and passed
    to the method as positional arguments, but the entire keyword-value
    mapping is passed as well.

  * Certain keyword arguments are expected; these are pulled out and passed
    to the method as positional arguments, and the remaining keyword-value
    pairs are passed as well.

I don't think any of these implementations eliminate _id and _message from
the keyword-value pairs that are passed along, although they might as well.
But this isn't a matter of "underscore keywords are special cased"; it's
simply part of the definition of cords that the _id and _message arguments
are used to determine context and behavior.  You can't say there's a
"special case" in which the _id and _message arguments are not passed along,
because there is no _general_ case in which messages go through two levels
of dispatch.

> 	#$#cord 3487 
> 		_id: I12345 
> 		_message: cord 
> 		__id: I48268 
> 		__message: delete-stroke 
> 		stroke-id: ...

If you defined a protocol that defined a cord type that had a cord message, you could have a perfectly valid way of interpreting this.  I don't think the spec says anything about it.

To reply to your other message, I have no real objection to moving cords out of the main spec.  Although I think anyone who doesn't implement them should be shunned and cast away.

--Erik