[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,
> but.

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 
mcp-negotiate-can alone.

Jay


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
download/upload messages.

Admittedly, I don't know if speed/ease-in-MOO *should* be an issue.

> ----------
> From: 	Dave Kormann[SMTP:davek@research.att.com]
> Sent: 	Wednesday, November 26, 1997 10:58 AM
> To: 	mcp-dev@research.att.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.
> 
> opinions?
> 				dk
>