[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

multiline syntax (was Re: Greetings and comments on MCP 2.1)

 >> #$#blah multiline* = 123 multline2* = 456
 >> #$#* 123 = The text goes here.
 > I strongly support this proposal to eliminating _data-tag: and find
 > this proposal superior to the alternative I proposed while back.  I'm
 > in the process of writing an MCP parser in Java with support for
 > multiline MCP messages.  The algorithm this proposal requires is
 > straight forward, in particular, using a separate data tag for each
 > multiline in one MCP message value greatly simplifies the parser.  I
 > take this as good evidence of the value of this proposal.

i really feel the algorithm here is not nearly as straightforward as
the one required to handle the single data tag, and moreover i think
that while this increases somewhat the human-readability of the
protocol, it comes with (i believe) an _increase_ in parser
complexity.  consider: to handle these messages you hafta count up the
data tags and make sure you get end tags for each of them, rather than
simply having one end tag that closes everything up.  since you can't
dispatch until you've finished assembling the multilines, this seems
much trickier to me.  in other words, in the current system, as soon
as you see an end tag, you can dispatch; in the proposed system, the
action on receipt of an end tag is something like 'increment
end-tag-count; check end-tag-count; maybe dispatch'

one idea that DID come up in verbal discussion is that we could really
dispense with the dummy values.  something like:

#$#foo 3224309 mult-val1* simple-val: foo mult-val2* _data-tag: 1234
#$#* 1234 mult-val1: yadda
#$#* 1234 mult-val2: foo foo bar bar
#$#end 1234

in other words, get rid of the useless : "" after multi-line tags.
i'm not particularly tied to this, but i think it's a LOT prettier.
maybe this is a human-readability thing again, but in this case, i
think it's coupled with a minor parsing simplification.

 > I'm not sure about equal sign vs. colon.  I guess I slightly prefer
 > the equal sign, but only very slightly.

my main reaction is that i think the = thing pretty much just goes for
human-readability in a protocol meant to be read by programs.  it
might make debugging simpler for some folks, but i don't think it's
true for an awful lot of people.
		all for human-unfriendliness