[DGD]Auto object

[Stephen Schmidt]

On Sat, 12 May 2001, Felix A. Croes wrote:
> Let's suppose that /usr/System/sys/objectd.c is supposed to be
> compiled with the include file that contains the inherit statement.
> Do you see a problem here...? :-)

Yes, except that if the object daemon isn't loaded yet, then
the driver wouldn't try to invoke path_special() because of
the absence of an object daemon: path_special() is not called
unless an object daemon has already been set. So I think
that that is not a problem.

> You've been putting far too much in /usr/System. 

That may well be the case, except that I was advised in response
to some earlier questions (not by Dworkin - the people who so
advised can identify themselves if they wish ;) that the entire
mudlib should be in /usr/System. I will have to rethink that,
obviously. I can't find the email in which were stated the
reasons why the entire mudlib should be put in /usr/System,
so I can't explain either what my question was, or why that
was the answer.

One point that had concerned me - as I understand it, any
object that is outside /usr (and also outside /kernel) has
no file writing privileges. That may not be a huge problem;
I should be able to run all the file writing processes
through the user object, which does have write permission
in, at least, /usr/System. However: Suppose I place Melville's
command objects in /cmds (rather than in /usr/System/cmds)
and a wizard (probably admin) wants to edit them. Can a
clone of /usr/System/obj/user.c obtain read privileges to
/cmds/foo/bar.c, and if so, how? I presume I need to wade
through the source code to see how the "admin" character
is handled in the kernel, and adopt that solution to my
problem. I'm a ways away from worrying about that now. But
since we're on the topic, here 'tis anyway.

Steve


List config page:  http://list.imaginary.com/mailman/listinfo/dgd