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

RE: Production release 1.8.0 of the LambdaMOO server

>> 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.
Home | Subject Index | Thread Index