Subject: 1.8.0 onc() change (was: Bug in 1.7.6?)

From: [email-masked] (Gustavo Glusman)
Date: Wed, 13 Oct 1993 00:13:35 -0700

Pavel writes:
>Now, that was the truth, but *should* it be so?  I propose in version 1.8.0 to
>eliminate the possibility of output from an open_network_connection() being
>treated as normal MOO commands.  Outbound network connections would be
>completely distinguished from inbound ones and only read() would drain the
>received output from the connection.
>
>I am aware that such a change would be incompatible with the way some onc()
>applications are currently written, notably at least one of the various MOO-net
>implementations.  I believe, however, that such a change would (1) make it
>easier to write reliable onc() applications, and (2) be much easier to explain
>to people.
>
>Since I am going to resume full-time work on 1.8.0 within the next week or so,
>now is the time to speak up about this proposed change.  Absent any persuasive
>arguments in favor of the status quo (and more persuasive than "but I'd have to
>rewrite parts of MOO-net"), I will implement the proposal.

I want to stress the phrase 'eliminate the possibility'.
IMHO, this is what you would be doing. Eliminating possibilities. I think
there is no improvement in this.
After all, all applications running read()'s would continue working, and
those relying on the parser would break down. It's not that you're now
enabling read()'s. (Get my idea? We're only losing possibilities with this
change.)

'Make it easier to write reliable onc() applications'... True, if you coded
your read()ing task wrongly, it would now work. This is appliable to many
common errors... and you don't plan to change the server for each of them,
right?
On the other hand, we *are* losing the powerful possibility of piping info
through the parser, which is currently the *only* way (as far as I know) of
activating command-line-only verbs (!x).
So some onc() applications would be made more reliable... if you think that
implementing a safety net is making a buggy program more reliable. I think
that if you don't have the safety net, the bugs eventually pop up, and this
is a good thing. See the example that started this thread...
But, while these apps would be more reliable, it would be *much* more
difficult to write onc() apps that need to call !x verbs. This is a big
loss, IMO.

'...much easier to explain to people.' Again, the onc() apps that would be
writable in 1.8.0 are writable now, but need only some task control. Once
they work, there's no difference in the difficulty of explaining them.

I have still not used the parser possibility (though I planned to do so
eventually). This means, I won't have to rewrite code if you implement the
change. But I still think I'm losing some possibilities... and some nice
ones at that.

Thanks for your attention.

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 13 Oct 1993 09:56:43 -0700

> Date:	Wed, 13 Oct 1993 00:13:35 -0700
> From:	[email-masked] (Gustavo Glusman)
> 

This is not true, because it would make it so much less difficult to write
onc() applications.  The current set-up, as Andrew Wilson has attested to, is
very vulnerable to bugs and imposes an onerous regimen on the application
writer for very little gain.  The applications that would work under the new
set-up and not in 1.7.6 are not buggy; they're simpler to reason about and they
ought to be made to work.

> activating command-line-only verbs (!x).

There are two answers to this.  First, it is possible, though gross, for either
the owner of a !x verb or a wizard to invoke it.  Let OBJECT:VNAME(@ARGS) be a
call we'd like to make to a !x verb; the following code in 1.7.6 would
accomplish the task:

	new_info = info = verb_info(OBJECT, VNAME);
	new_info[2] = new_info[2] + "x";
	set_verb_info(OBJECT, VNAME, new_info);
	new_code = verb_code(OBJECT, VNAME);
	new_code[1..0] =
	   {tostr("set_verb_info(", OBJECT, ", ", VNAME, ", ",
	          $string_utils:print(info), ");"),
	    tostr("set_verb_code(", OBJECT, ", ", VNAME, ", ",
	          "code = verb_code(", OBJECT, ", ", VNAME,
		  ")[3..length(code)]);")};
	OBJECT:(VNAME)(@ARGS);

As I said, this is gross but it is possible.  In 1.8.0, I intend to change the
semantics of the `x' bit to always allow calls from code running with the
permissions of either a wizard or the verb owner.  Thus, the `x' bit would work
analogously to the `r' and `w' bits, controlling only the abilities of
non-wizard non-owners.

	Pavel

---

From: [email-masked] (Erik Ostrom)
Date: Wed, 13 Oct 1993 12:11:19 -0700

> As I said, this is gross but it is possible.  In 1.8.0, I intend to
> change the semantics of the `x' bit to always allow calls from code
> running with the permissions of either a wizard or the verb owner.
> Thus, the `x' bit would work analogously to the `r' and `w' bits,
> controlling only the abilities of non-wizard non-owners.

Will it also be possible to call different verbs with the same name
programmatically?  At the moment, even with gross hacks for calling !x
verbs, it's impossible to replicate the built-in parser; given a verb
"take any from this" and another verb "take this none none" on the
same object, one of them can't be called.

---

From: Pavel Curtis <[email-masked]>
Date: Wed, 13 Oct 1993 18:48:48 -0700

> Date:	Wed, 13 Oct 1993 12:11:19 -0700
> From:	[email-masked] (Erik Ostrom)
> 

I refer to this general problem as the `verb-naming tar pit'.  I will at least
put something in 1.8.0 like Rog's verb-numbering idea, including support for
calling verbs by number.  It is possible that something much heavier will be
provided in addition, to allow one to get a handle on a verb that stays
meaningful even in the face of renamings and renumberings.  We already want
something like this for solving some basic security issues in the Jupiter
window system.

	Pavel

---

From: Roger Crew <[email-masked]>
Date: Fri, 15 Oct 1993 22:48:00 -0700

>   In 1.8.0, I intend to change the semantics of the `x' bit to
>   always allow calls from code running with the permissions of
>   either a wizard or the verb owner.  Thus, the `x' bit would work
>   analogously to the `r' and `w' bits, controlling only the
>   abilities of non-wizard non-owners.

I'll also suggest

(1) allowing -x verbs to be called as hooks from server builtins
(2) having server builtins completely IGNORE verbs with satisfiable 
    argspecs (i.e., NOT `this none this') when searching for hook verbs.

By "hook" verbs, I mean :accept, :enterfunc, :exitfunc, :recycle, etc...

The one-line justification for (1) is that if the wizards can do it,
the server should be able to do it, too.  

The real win, however, is that this provides a way to distinguish
between server calls and non-server calls to a hook verb.  Simply put,
if you care that other programmers might be calling your :accept verb
explicitly, you can set it -x to prevent them from doing so, thus
guaranteeing that any call this verb gets is from a bona-fide move()
(or some wizard code that knows what it's doing).  Note that if there
is some functionality in that verb that other programmers need to get
at, it's a simple matter to push that off into another verb
(cf. :acceptable on LambdaMOO) which can then be made +x.

The principle behind (2) is to keep separate the use of a particular
verb name as a server hook (:accept for move()) and as a command verb
("accept money from Joe").

Note that the current situation also loses in that if you
have an "accept" command and there's some reason you *want* to make it
+x (e.g., to allow children to pass() to it), you are then back to solving
move() detection problem...

In any case, if you do (1), then (2) is necessary to prevent the
confusing situation in which a command verb in existing code suddenly
finds itself being called as a server hook.  Since -x command verbs
will necessarily have satisfiable argspecs, (2) will suffice to ward
against this.

--
Roger Crew
Internet:   [email-masked]
LambdaMOO:  Rog