Re: [PROPOSAL] _data-tag values give vector length

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

(gah, accidentally just replied to john on this subject.  anyway, i
said i thought this idea was cool)
Michael Brundage writes:
> This is the sort of thing that I think should not be a part of the MCP spec, 
> but which individual clients should be able to do.  That is, the general 
> mechanism by which data-tags work is a part of MCP, but the specific way 
> your client and server code manage them is a part of your particular 
> dialect or implementation of MCP, say FuzzyWuzzy.  Then FuzzyWuzzy might say 
> "All data tags will look like this" while other types might specify 
> other formats.

the thing is, it's impossible to make ANY real use of the dummy value
right now, since there isn't even a suggested use for it; if it's just
suggested to be an empty string, you can't put anything in it and even
have a vague hope there'll be clients able to cope.  if we suggest you
put in a linecount, we could say, 'hey, if it's a positive integer,
it's a linecount, otherwise, it's a dummy', leaving the rest of the
typespace (i.e. alphabetic strings) open for other uses.  but on the
other hand, it's possible this is an overcomplication.

> For what it's worth, Jupiter didn't do multiline values in this way at 
> all; instead it "slasified" multiline values into a single (quoted) 
> string, and then just put it all on a single line.  This led to some 
> rather large strings, and some significant inefficiencies on both sides 
> of the channel, but at least it did work...

i think our current system works; what we want is something that works
well enough to satisfy implementors and users without running us up
against serious potential technical problems (as smashing everything
into a single line does; i know you're not suggesting that, i'm just
trying to explain what i'm about here.)
				dk