Subject: Another approach to the onc() issue

From: Pavel Curtis <[email-masked]>
Date: Wed, 13 Oct 1993 10:05:01 -0700

It has been pointed out to me, in private mail, that one of the other ideas I
would like to implement for 1.8.0 has a bearing on the onc() debate.

The idea relates to the known kluginess of the current way that
#0:do_login_connection() must use in order to connect a network connection to a
particular player.  Since the verb must return, without ever suspending or
read()ing, a valid player object, a certain class of useful operations (such as
prompting for information, performing various onc() tasks, etc.) cannot be
included in the login process.

A better solution would involve the provision of a new wiz-only built-in
function for attaching a specified network connection to a specified valid
object.  The returned value of #0:do_login_command would no longer be relevant
and the server would no longer care whether or not such tasks suspended or
called read().

Of course, with such a mechanism, an onc() application could presumably arrange
to attach an outbound connection to a specified object and then use the verbs
on that object to respond to the output on the connection, if it so chose.

I am likely to implement such a facility in 1.8.0 (though I admit that the
design is not yet entirely clear to me), so that may also sway the onc()
debate.

	Pavel

---

From: Roger Crew <[email-masked]>
Date: Wed, 13 Oct 1993 20:44:45 -0700

There are actually two problems with using a while loop to read from
an outbound connection.  Divorcing the command parser from the
situation would only solves one of them (i.e., that of input being
stolen by the command parser if the reader dies).  The other is that
you actually have to go to some effort to keep a reader task running.
If something in your while loop bombs or run out of ticks, the
connection starves as pending input NEVER gets read.  Now you could
have some other task periodically checking that your while loop is
still alive, but of course *that* task could die, too... 

This is why I like the notion of being able to transfer the connection
to a valid object that defines its own command structure.  The whole
problem of keeping a reader alive is left in the scheduler where it
belongs.

Moreover, I think this is rather inextricably tied to the question 
of how a PLAYER object can define ITS own command structure, since it 
would be simplest if the two situations were made as similar as possible.

Anyway, here's a proposal:

At any given time, 
(1) each connection is attached to exactly one object #n.
(2) each connection may be "held" by some task.

"held" means that it's an error for task other from the holder to
attempt to read() from the connection.  A connection is "free" if
it is not held.

Calling read() on a free connection makes it a held connection.
A connection that starts a command task (see below) is held by that task.
onc() creates a connection held by the current task.

Any held connection remains so until the holding task either 
 (1) finishes
 (2) suspends
 (3) reads from a different connection.

Just to be specific about what a "command task" is:
    Whenever queued input exists on a free connection #n, the server can,
    at the scheduler's discretion, 

      call #n:do_command(...)      if #n is valid and that verb exists
      call $do_login_command(...)  if #n is invalid

    These calls are made with player=#n and argstr=<command line> and
    the resulting task is a "command task".

Note that if #n is valid but has no :do_command verb, 
then only read() can retrieve input from that connection.
Thus, those who want to write their own while loops would still be
able to do so.

Clearly, $player:do_command() is that in-db parser everybody wants.
If wizard code can call -x verbs and verbs may be called by number, then
there really isn't any further obstacle to ditching the built-in parser.
Of course, now you REALLY get screwed when you chparent to #-1, but hey...

With a transfer_connection() primitive, $do_login_command() can now read()
with impunity, though there will be trouble if it suspends since the user 
could get another instance going during that interval.
--
Roger Crew
Internet:   [email-masked]
LambdaMOO:  Rog