Re: protocols, messages, cords, oh my!

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

> yet another alternative, btw, is to use a special character to
> indicate the separation between protocol name and message/cord name.
> for example,
> 
>   mcp-cord:open
>   mcp-cord:msg
>   mcp-cord:close
> 
>   whiteboard:main
> 
> This would ease parsing and allow us to eliminate restrictions on the
> number of words in a message.

This seems like a neat idea, but it's going to break a lot of design
work my group's done already, and I'm not relishing explaining to them
that we need to rename every message we have, both in code and in
documentation.  I suspect if such a global (and semigratuitous) change
in message names and protocol semantics comes out as standard, the
rest of my group is going to look at me like I'm a loon and suggest
that we "postpone" complying with the standard for another release
cycle or two.

I guess I'm a little skeptical about such radical changes for 2.1;
maybe 2.2 or 3.0, depending on what your interpretation of "minor
change" is.  The nice thing all the changes we've discussed before
this was that I could keep them nicely inside the MCP
parse/decode/dispatch box.

I'll give my interpretation of protocol names for the record: No
protocol shall define a message for which the protocol name is not a
prefix; suffixes shall either be empty or start with "-".

Intuitively I consider protocol and message names to be "-" separated
lists of words, which gives my interpretation a little more sense than
the pure character-based definition in the previous paragraph.

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