# Production release 1.8.0 of the LambdaMOO server

"Seth I. Rich" (sir@po.cwru.edu)
Tue, 12 Mar 1996 11:30:45 PST

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

    >> If you must do something like this I would MUCH prefer the following:
    >>
    >>  -- If a built-in function FOO has been made wiz-only (by defining
    >>     $server_options.protect_FOO with a true value), and a call is made
    >> to that
    >>     function from ANY VERB NOT DEFINED ON #0,
    >>                   === ----------------------
    >>     the server first checks to see if the verb #0:bf_FOO exists.
    >>     If so, it calls it (REGARDLESS OF THE PERMISSIONS OF THE CALLING
    >> VERB).
    >>     If not, E_PERM is raised if the calling verb is nonwizardly
    >>       (i.e., same behavior as before if #0:bf_FOO doesn't exist).
    >
    >Problem with this:  $server_options.protect_FOO doesn't mean what it's
    >supposed to any more.  .protect_FOO is supposed to mean that foo() is
    >wiz-restricted.  Now it means that *nobody* can call foo(), except from
    >#0.  This seems to me to be a much more serious illogicality than the
    >current system (not to mention backwards-compatibility).

    Although it makes sense, from several perspectives:

    - When a programmer calls foo(@args), it's 100% consistent what happens.  If
      $server_options.protect_foo exists and is true, then either #0:foo(@args)
      is caller or E_PERM is raised/returned, otherwise foo(@args) is called by
      the server.  (These rules are suspended for builtins called from #0.)
    - The behavior of a builtin should be consistent regardless of who calls it.
      (Yes, queued_tasks() is the exception to this, but I'd also love to see
      that changed.)

    For my personal uses, this change would make much more sense.  I've written
    wrappers for almost all db-modifying builtins, and I'd -love- to be able to
    just have the server deal with forcing the #0 wrappers to be called.  However,
    this change is almost useless to me if wizardly calls stomp forward and
    ignore the wrappers.

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

    Why do you think this is the most likely case?  Why would one write a wrapper
    which didn't do anything?

    >> The problem with the previous version is if I'm looking at some random
    >> verb in the db and I see a call `create(...)', given that #0:bf_create
    >> could do completely arbitrary things, I have NO IDEA what this call is
    >> going to do unless I know the wizardliness of the verb.

    >You have no idea what any code is going to do unless you know what
    >permissions it's going to run under, including whether they are wiz perms
    >(or programmer perms, and the individual player.) You never have and you
    >never will.

    This is an incorrect claim.  If I look at verb code, I can tell what it's
    going to do, or at least boil it down to a set of possibilities (it may
    bomb here, it may bomb there, and so forth).  If we introduce the possibility
    that under some circumstances it may call verbs on #0 instead of the
    builtins themselves, and this is determined based on the player's .wizard
    bit as opposed to explicitly by code, we can't predict behavior anymore.

    Take another example -- some time ago people wanted to "regularize" the x bit,
    so that a programmer could call any verb she controlled as if its x bit were
    set.  I objected to this for the same reason -- the language should have the
    same result, if given the same command.

    >The permissions of a verb determine what everything will do:
    >what verb calls do, whether property assignments work, what built-ins will
    >allow you to do, etc.

    But those permissions don't cause the server to make assumptions which
    will result in different code being called, silently.

    Seth / Blackbriar
    ----------------------------------------------------------------------
    Seth I. Rich - sir@po.cwru.edu
                                     There is nothing more precious than
    Rabbits on walls, no problem.    a tear of true repentance.