MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Non-overrideable verbs

At 10:29 -0800 7/28/96, Jefferson M. Dubrule wrote:
>Here's a server modification I have been working on.  Any comments?
>One change that I've been considering is a modification to add verb arguments
>into criterion for overriding:
>this way, "l*ook this none none" would not override "l*ook any in this", for
>example.

Well I'm not sure this is the most useful example of the 'power' of blocked
(non-overidable) verbs. Another example could be:
A E_MOO we have $object which is a class root of all valid() object of the
db (including $garbage & co...) on it we put all the verbs to interact with
objects (verbs usually found on $perm_utils, $quota_utils and
$object_utils); if you want to know if object foo is a $bar, just call
foo:isa($bar) of course $object:isa is +b (blocked, i.e. non-overidable).

>Thanks to Richard Godard for sending the message to moo-cows suggesting this.

Welcome. :)

>**********************************
>* Draft:  -o_Verbs               *
>******************************************************************************
>* Date:                      07/27/96   Patches needed:                 None *
>* Written by:                   manta   ICBINL?                 More-or-less *
>******************************************************************************
>
>*	Each verb is given a new possible flag 'o' for "overrideable"

When non-overidable verbs were implemented at E_MOO and TecfaMOO we
discussed the naming and came to the conclusion that having 99% of the verb
of the db to have a o bit would be spammy. We thought about naming the
non-overidable verbs 'finals' but then a f bit could have confused the weak
minds that we are with the fertile bit... we could have gone for protected
but a better usage for p would be passable verbs (i.e. -x verb that would
accept the to be called by pass())... after some discussion of the NetWiz
channel of the GNA-network, the name blocked and the b bit came out (I
think the credits are for Knekkebjoern@Meridian or Phantom@Bay)

>*	This flag is set using add_verb(), or set_verb_info().  Only
>wizards and owners of the verb can change the setting or a -w verb.

In fact allowing a $server_options.protect_blocked_verbs flag that if set
to true make the privilege of changing the b bit wiz only, can be a good
thing.

%< snip %<

>*	set_verb_info() can cause four types of conflict:
>	*	In a call to rename a verb, the new name conflicts with a
>-o verb on an ancestor.  A call that would cause this conflict would
>return E_PERM.
>	*	In a call to change the owner of a verb that overrides a verb
>on an
>		ancestor to a non-wizard or an owner other than the owner
>of the overridden verb.  A call that would cause this conflict would
>return E_PERM.

I both case I would rather raise E_NACC (move refused by destination), that
would be easier then to give feedback to the user... (and in some way it's
a 'move' refused by the dest :)

>	*	In a call to change the flags of a +o verb to make it -o, a
>conflict is created by a verb on a descendant.  A call that would cause
>this conflict would return E_INVARG.

(1) Please also me to disagree with that. It would be a major pain to be
returned E_INVARG. If you set a verb +b (i.e. -o) and that this make a
conflict with the descendants, well I would say up to you to decide if the
verbs on the kids are a thread... when I implemented the b bit I though of
it like the c bit for properties... is you make a -c prop +c, it will not
change the ownership of all the kids, not raise you E_INVARG at the face...

>	*	In a call to rename a -o verb, the new name conflicts with a
>verb on a descendant. A call that would cause this conflict would return
>E_INVARG.

Again I would suggest E_NACC... the argument is perfectly valid... it's the
change ('move') that is refused.

>
>	*	add_verb() can cause two types of conflicts:
>	*	The new verb conflicts with a -o verb on an ancestor.  A
>call that would cause this conflict would return E_PERM.
>	*  The new verb is -o and conflicts with a verb on a descendant.  A
>call that would cause this conflict would return E_INVARG.

See (1)

>	*	chparent() can cause one type of conflict:
>	*	A verb on the object or one of its descendants conflicts with a
>-o verb on the new parent or one of its ancestors.  A call that would
>cause this conflict would return E_PERM.
>
>*	In the server, the flag will be E_NOT_O, and a 1 will indicate a -o
>verb
>	and a 0 will indicate a +o verb.  This will mean that no database
>	translation will be necessary when the patch is applied.  Under the
>current
>	server code, a database featuring +o and -o verbs is compatible with a
>	database without them with no translation.

If you do this... you will 'kill' the server during the name conflict check
when doing operation on $root_class/$room/... on a large MOO. The tree to
search on will simply be too large.

I implemented it in-db as a database of blocked verb, so I don't have to go
through the whole tree to look at conflicts. And even that way it need some
suspend (of course in-server it should be much faster) so I had to
implement a FIFO queue for add_verb()/chparent()/set_verb_info() calls... I
know it's ugly but that was the only way I could think about to to avoid to
run out of ticks or to generate security holes...

Now having such a db in-server would require to store it during
checkpoint/shutdown, which would lead to uncompatible db with other version
of the server... hmmmms unless you store it as verb flags during the db
dumps and rebuild the db at boot time... this may be a solution to have
both speed and compatible db formats... <shrug> I'm not a server expert...

SO I think we better cross our fingers and hopes Joe likes the
non-overridable verbs and plan to implement them in a future release of the
server because I don't think a lot of people would trade incompatible db
for non-overridable verbs (when a in-db solution is available :-)

Anyway, Good luck. That was just my $0.02 :)

Richard
References:
Home | Subject Index | Thread Index