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

RE: Some comments on the spec...

[... at the risk of further flogging this horse to death...]
[... actually, there are new arguments, here; I now have 
     a much better handle on what I don't like about #$#mcp-quote...]

    3. [Network Line Translation section]
       Here is how I reconstruct what seems to be the desired
       computational model.

       It seems that the desired structure of an MCP processor is as

        (network lines) ->  [Splitter]
                              |     |
                              |     ---------------
                              |                   |
                              v                   v
                      (in-band lines)       (out of band lines)
                              |                   |
                              v                    v
                      [In-band processor]       [MCP assembler]
                                                (MCP messages)
                                                  |  |     |
                                                  v  v ... v
                                                 [MCP modules]

This is correct except that I've fixed your terminology.  I really only
intended "network line" to refer to the line in the form that it was
transmitted over the network (i.e., only the incoming line, which may not be
the same as the line that emerges from the splitter, and, in the case of
quoted in-band lines, isn't).  "In band" and "out of band" weren't supposed
to be kinds of network lines but rather were to refer to the lines produced
by the splitter (though, admittedly, a given network line will only
translate to one or the other).

   It seems to me that there are three possible solutions to this

   1. Set aside a special protocol:

     #$#mcp-quote <authkey> line: <value>

    This protocol will call the In-band processor with

    The advantage of this scheme is that the splitter is
    completely trivial. Only in the specialized case of wanting
    to have a #$# in-band line is some specialized processing
    invoked ... and then it is invoked in the standard way, as an MCP

    The disadvantage is that one has to make the (modest) architectural
    assumption that the In-band processor is callable from MCP


  3. Introduce a new classification of network lines: out-of-band
    (those beginning with #$#), quoted in-band (those beginning
    with #$") and in-band (the remaining). ...

[Why I prefer (3)]

First of all, not that this should matter, but for the MOO server, the
"modest" assumption is in fact a major obstacle.

Secondly, simply being able to invoke the in-band processor for #$#mcp-quote
lines does not suffice, seeing as the in-band processor generally cares
about the ordering of the lines it receives and may even be modal (e.g., has
distinct command and read() modes) as well.  Quoted in-band lines must be
re-inserted into the in-band stream at the point corresponding to where they
occurred in the network stream.

If quoted in-band lines are not identified until MCP dispatch, then the
processing of in-band lines and out-of-band lines must be SYNCHRONIZED:
That is, before the next in-band line may be processed by the in-band
processor, the previous out-of-band line must first be processed by the MCP
dispatcher to the point where it is known that said line is not actually a
quoted in-band line.

This is one of these simplicity-is-in-the-eye-of-the-beholder situations.
Of the possibilities

       trivial splitter + synchronization requirement
  less trivial splitter + no synchronization requirement

I consider the latter to be simpler.

To be sure, the MOO server (almost) automatically satisfies any
synchronization requirement by virtue of being single threaded, but the same
is not necessarily true of the clients and other kinds of servers (and
perhaps even future MOO servers).  

An Emacs client might, e.g., have a process filter that leaves in-band lines
behind in the main process buffer and puts OOB-lines onto a queue for
processing by the MCP dispatcher; if in-band quoting were expressed as an
MCP message, either the filter needs to be parsing for that message, or
*every* OOB line would need a corresponding marker pointing to where in the
main buffer that line was extracted so that the MCP dispatcher would know
where to replace it if need be...  
... I'm not saying this isn't doable, it's just not *simpler*.

   The counter to this is that an implementation could, of
   course, choose to implement the parsing of this particularly
   simple MCP mesage inline, i.e. in the splitter.

which basically means you're doing (3).