[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ok, sent out the first batch of changes.
> so, i've changed the mcp message to use version: and to: instead of
> min-version: and max-version:. any feelings on whether the
> mcp-negotiate-can messages should ALSO have their args changed?
> probably not, since there's no need for backwards compatibility there,
What's more, non-mcp users won't see the mcp-negotiate-can messages;
they will see the #$#mcp version: 2.1 message. I'd leave
I think I agree with dave, here.
One other point is that if the issue is being able to do it easily in MOO,
doesn't $do_out_of_band_command() in MOO have argstr available?
I'm not entirely convinced that the overhead of slashification, which
requires walking through every character of every data string, will be that
small, *particularly* if making it easy/fast on MOO is an issue (since MOO
is an interpreted language, CPU time spent by the quoter may yet be
significant compared to network time spent, especially since it's a
per-character cost rather than a per-line cost --- even if the CPU itself is
sufficiently fast that this isn't a problem, there's still the added
complexity of dealing with tickouts). I also would think that multilines
would comprise the majority of the traffic; if someone connects, does a
local edit on some 500-line object, and then disconnects, that's basically
1000 lines of #$#* to compare with the 10 or 20 version-negotiation and
Admittedly, I don't know if speed/ease-in-MOO *should* be an issue.
> From: Dave Kormann[SMTP:firstname.lastname@example.org]
> Sent: Wednesday, November 26, 1997 10:58 AM
> To: email@example.com
> Subject: Re: official release
> > Can we *please* quote the values associated with multiline bodies?
> > We can unify parts of the BNF and reuse the single-line parsing
> > implementation. Aside from the usual excuses of concept reuse and
> > coherence this also means the MOO implementation can (as usual) just
> > use the MOO tokenizer. The overhead of the additional slashification
> > for quotes and backslashes is pretty small and we know that any MCP
> > implementation already has this functionality available.
> i still think this is a lose. the additional parser complexity to
> handle unquoted multilines is as near to nil as makes no odds, and
> it's _really_ nice being able to just spam multiline values across the
> link. as i said before, i'll go for this change if there are a
> sizable number of people in favor of it, but i _really_ don't think
> that being able to use the MOO reader or cutting a very small branch
> out of the BNF really buys us anything against that.