re: Multilines necessary?

[Dave Kormann <davek@research.att.com>]

William Drury writes:
[...]
 > Are multiline messages really just a specific instance of a cord?

not really.  now, you _could_ implement multilines by defining a cord type
"multiline-message" and, for example, sending the cord id in the value
slot of an argument which is supposed to be multiline.  but that just
seems like gross overkill to me.  really, multilines serve two very
simple purposes: they shorten the length of an individual MCP message
line and preserve linebreaks.  cords, on the other hand, essentially
give you multiple MCP sessions inside a single connection.  while a
simple application of this is to implement multilines, that's also
more effort than you should need to go to.

another, more subtle difference: the only state guaranteed to be saved
between two messages sent along a single cord is the cord ID.  except
as part of an individual cord protocol's definition, you can't expect
clients and servers to remember previous messages (and probably it's
best to avoid designing for statefulness in your cord-based
protocols).  in multilines, on the other hand, we rely on one end of
the connection maintaining state between messages so that we can build
up the final form of the argument.

that's probably a bogus distinction, given that you can always define
the protocol to require saving state between messages, but it seemed
like a good idea when i started typing it.

a final, even more bogus distinction: multilines are a requirement (i
think they pretty much HAVE to be) and cords aren't (they're only
recommended).
				dk