Re: Message arguments for chords...

["Jay A. Carlson" <nop@kagoona.mitre.org>]

> > gah, yeah, this is broken.  i'm for making '_' reserved by #$#cord,
> > any objections?

> What happened to the proposal that '_' keywords are reserved for future 
> versions of the MCP spec?

I thought that '_' keywords are reserved for the protocol itself.  I
guess this comes down to whether you consider cords to be in the core
or a user-level extension.

> Note that another way to go is simply to say that all arguments besides
> the specific arguments '_id' and '_message' are passed along to the cord.

This was I think my original intention.

> For that matter, one could as easily say that ALL arguments are passed
> along to the cord; the cord just won't have any use for the _id and
> _message arguments.  This fits very naturally with the "drop excess
> baggage on the floor" philosophy expressed elsewhere in the spec.

> More generally, do we have a rationale for the cord keywords using
> '_id' and '_message' instead of 'id' and 'message'?  If

If we do this, the messages conceptually carried along a cord can't
have keys named "id" or "message".

My rationale: in some sense a #$#cord (whine about return "mcp-" +
message_name; coming up in a bit) wraps an arbitrary user-space
message and directs it to a destination.  I toyed with the idea of

#$#cord id: 123 message: "#$#asdf bite: \"me harder\"" 

but got grossed out by it.  I guess if you want to be able to do this
wrapping indefintely this works better because we can deal with
multiple levels of encapsulation, or we could prepend _ to all the
message names from the previous level, or whatever.

They claim they may be panicking the machine I'm on in a couple
minutes so maybe I had better send this now.

Jay Carlson   nop@kagoona.mitre.org    nop@nop.com
The MITRE Corporation, Bedford MA

Flat text is just *never* what you want.       ---stephen p spackman