RE: Production release 1.8.0 of the LambdaMOO server

• Date: Mon, 11 Mar 1996 23:33:22 PST
• From:
  Jefferson.M.Dubrule@dartmouth.edu (Jefferson M. Dubrule)
• Reply-To:
  manta@dartmouth.edu (manta)

--- Christopher Unkel wrote:
>Under your proposal, if you want a built-in to be wizard-restricted (or 
>have one currently that is this way), you have to write #0:bf_FOO:
>
>if (caller_perms().wizard)
>  FOO(@args);
>endif
>
>Given that this is the most likely case of wanting to modify the behavior 
>of a built-in, it seems silly to force this code to be written over and over.

Actually, the code could look like this and only exist once:

.program #0.bf_*
try
   protected = $server_options.("protect_"+verb[3..$]); 
except (E_PROPNF)
   protected = 0;
endtry

if (!protected || caller_perms().wizard)
				set_task_perms(caller_perms());
    return call_function(verb[3.$],@args);
else
    return E_PERM;
endif
.

My personal idea on the matter is this:

FOO() is called by a $luser/$wizard

If $server_options.protect_FOO exists and is true, and !callers_perms().wizard,
return E_PERM.

Provided we haven't bounced the $luser out on an error, 
   if #0:bf_FOO() exists, call it instead of the built-in, unless the calling
verb is #0:bf_FOO().
   otherwise, go ahead and call FOO().

This seems pretty straightforward, and provides a wizard with the ability
either to protect all built-ins with the $server_options method or to filter
them manually.  It also gives a wizard the ability to replace built-ins with
another action, yet still allows the built ins to be called under special
circumstances or as part of the #0.bf_FOO() itself.

A tiny amount of backwards compatibility is lost, but the new server has only
been out for what. . . 3 days?  The grief would be minimal.  As well, it would
be very easy to change code written for 1.8.0p1 to this system.

If backwards compatibility is REALLY desired, a notion of
$server_options.armour_plate_FOO could be developed and it would work this way.

To recreate your supporting example:
>Supporting example: $server_options.protect_create is set true because
>programmers are calling raw create() instead of requesting an object from
>the recycler, resulting in skyrocketing max_object() and gobs of recycled
>objects just sitting around.  #0:bf_foo is written to call the recycler's
>create; problem solved. 
>
>However, there needs to be some way to call the built-in create, because:
>(1) Sometimes a fresh object is really desired, for example when creating 
>new players, and
>(2) The recycler's create is going to need to call it if there are no 
>recycled objects available.

Under my system, this would work as follows:

(1)  Leave $server_options.protect_create at 0.
(2)  Write the #0:bf_create() as follows:

.program #0:bf_create
if (caller == $recycler && callers()[1][2] == "do_hard_create")
   return create(@args);
else
   set_task_perms(caller_perms());
   return $recycler:create(@args);
endif
.

Problem solved.  Now if a wizard REALLY wants to do a create(), s/he calls
$recycler:do_hard_create.
This is as it should be as the $recycler has taken over the job of managing
object creation, recycling.
For other problems, a more complicated perms check could be done.

I am currently working on a couple of patches to the server that will render
many of the built-ins meaningless.  It would be nice if I could redefine some
built-ins for everyone (including .wizards) with out resorting to more server
hacks.

FYI, the patches I am working on are "verbing properties" and multiple
inheritance.  When I have shaken the problems out of the drafts, I will post
them.  When I have finished the patches, I will make them
available.

-manta

• Prev: RE: Production release 1.8.0 of the LambdaMOO server
• Next: RE: Production release 1.8.0 of the LambdaMOO server
• Index: MOO-cows
• Thread: MOO-cows