Re: [SERVER] optional verb call by server

• Date: Mon, 25 Mar 1996 20:37:52 PST
• From:
  rgodard@divsun.unige.ch (Richard Godard)
• Content-Type: text/plain; charset="us-ascii"

>> potentially undesireable "side effects".  For example move() always checks
>> accept(), among other things.  One MOO that I've seen implemented the builtin
>> priority_post() to move things unconditionally.  Perhaps either more
>> $server_options or new, simpler builtins could be added)
>
>For what it's worth, I wrote a trivial change to the way movement is
>handled for IdMOO.  Instead of calling WHERE:accept(WHAT) as tradition
>dictates, the builtin calls #0:accept(WHAT, WHERE), and #0:accept is
>programmed to call WHERE:accept(WHAT) normally.  I'd propose that people
>interested in de-side-effecting builtins follow that course instead of
>making an all-or-nothing server option.
>Def.

Well I made a patch that allow to disable (from the db, through properties
on $server_options) any of those calls:
initialize/recycle/exitfunc/enterfunc/accept.

E.g. if $server_options.disable_initialize_call exist and is true, then a
call to create() will NOT make the server call new_obj: initialize...

This allow me that kind of wrapper:

@program #0:bf_create
set_task_perms(caller_perms());
obj = create(@args);
this:init_owners(obj)
/* I'm happy, the obj.owners property is initialized, multiple ownership is
consistent */
try
   obj:initialize();
except (E_VERBNF)
endtry
return obj;
 .

As you can see, it's not all or nothing... it just allow you to move a verb
call from the server to the db...

With $server_options.disable_accept_call == 1, you could write a wrapper
like that:

@program #0:bf_move
set_task_perms(caller_perms());
if (#0:accept(@args))
  return move(@args);
else
  raise(E_PERMS);
endif
 .

Doesn't it offfer as much flexibility if not more ?

Suggestions and comments are welcome.

R.

• Prev: Re: [SERVER] optional verb call by server
• Next: Re: [SERVER] proposal for extensions.c
• Index: MOO-cows
• Thread: MOO-cows