# Production release 1.8.0 of the LambdaMOO server

Jefferson M. Dubrule (Jefferson.M.Dubrule@dartmouth.edu)
Mon, 11 Mar 1996 23:33:22 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    --- 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