[DGD] Methodology: Directory structure & Areas

[Noah Gibbs]

--- nihilxaos at nihilxaos.com wrote:
> /kernel directory is not to be modified

  Correct.

> The /usr directory holds most of your code.

  That's the common setup, though it's not mandatory. 
Basically the Kernel Library gives a bunch of
privileges and hooks to stuff in /usr/System, which
then farms it out any way it feels like.

  But in the usual setup, most of your code winds up
in /usr/System.  Phantasmal adds another layer called
/usr/common.  Note that due to the name, Phantasmal
also has to be careful to never let anybody make a
character, especially a wizard, named "common" :-)

> For some things, though, you want directories
> outside of the initial structure.

  Yup.  I'm a big fan of these, though the Kernel
Library seems not to be.  It's a matter of taste.  You
can get away with having none of them at all, or you
can use them for almost everything.

> What I'm debating with myself right now is where to
> put my domain directories. 
> Older MUDs that I've seen just lets each builder
> keep their objects under their 
> own directory trees. This is all well and good, but
> it encourages tinkering and 
> can lead to errors.

  Bear in mind that admins *should* be able to do some
amount of tinkering in their own areas, and their own
directories are one fine place to put that code.  With
that said, Phantasmal tries to encourage admins to
never put anything in their own directories, and
instead build directly in the MUD domain files.  If
you want a tinkering area, simply cut it off from
non-admin access by making sure there are no exits
that lead to it (and eventually through a "locked to
players" zone flag to avoid accidental teleportation).

> This is especially bad in terms
> of guild objects or 
> commonly used items and areas. This is especially
> bad if your characters' 
> equipment is persistent at all. That sword they
> carry may change from day to day.

  To some extent this is likely to happen anyway.  The
objects have to exist *somewhere*, and they almost
certainly need to be mutable.  But you're right,
putting the object into the home directory of the
creating admin is just asking for trouble.

> My main question is where is the best place to put
> these? 
> 1) An external directory.

  Obviously (if you look at Phantasmal) I'm in favor
of this.  I think it solves the problems best.  It's
also the least like the traditional LPMUD solution,
but I didn't come from an LPMUD background so I
couldn't care less.  I'm a big fan of the idea that
everything that anybody builds should be reasonably
viewable, even if it's not done yet.  I'm also a fan
of the idea that content and access privileges should
be decoupled -- it should be easy to grant and remove
access to things without having to create, destroy or
move them.

> Make a directory such as
> /domains and put each domain 
> tree under that. Perhaps even have a different root
> directory for each domain, 
> though that may get cluttered.

  Yeah.  I put all this stuff under a subdirectory and
then separate it out into zones (my equivalent of
domains) when saving.  So each domain is in a
subdirectory of the main one.  Then again, Phantasmal
has a rather odd setup for an LPMUD, and the code
doesn't wind up going in those directories (mostly).

> 2) In the domain admin's directory. Thus if "bob" is
> in charge of the "hell" 
> domain we'd have /usr/bob/hell as the root for that
> domain's stuff.

  I agree with Stephen Schmidt about why this is a bad
idea.  It's fine for only a single user, but in that
case why do you care where it goes?

> 3) In it's own user directory. Thus you would have
> /usr/hell to hold the domain 
> files for hell, and bob would have write access on
> it given the previous 
> example. In this case, though, hell still wouldn't
> be an interactive user like 
> System.

  Again, agree with Stephen Schmidt.  Easier not to
confuse your namespace of users.

> Which system do you guys think works best for this?
> My biggest question on #1 
> is whether or not the kernel mudlib has any problems
> executing code that 
> doesn't reside in /kernel or /usr, and if so is
> there an easy way to work 
> around that?

  The Kernel Library has no trouble executing code
anywhere.  It makes some assumptions about permissions
based on filenames, though -- something whose path
contains "/lib/", for instance, is guaranteed to be an
inheritable, not a clonable.  But everything about
reading, writing and executing can be set with the
various permissions commands, so if you want a
directory protected differently, just change its
permissions.

  At some point I have to get around to writing up the
Kernel Library's rules about pathnames and what they
mean...  I keep meaning to.  There's no serious
documentation on it that I know of, I just figured it
out by reading through the code.

> BTW...this list rocks!

  Thanks :-)  You're asking unusually good and
detailed questions, which definitely helps.  And you
seem to have read most of the obvious documentation,
so you're also making more progress in between
questions than the average petitioner.

  There's also the fact that the documentation's
better than it was.  I take significant pride in my
tutorial on building a MUDLib based on the Kernel, for
instance.

> Well...back to making sure I have DGD's inheritence
> system down before I code 
> much more. :)

  Yeah.  Really understanding it is tough, and pretty
much requires writing or debugging an Object Manager. 
Luckily, you've got at least two full-on Object
Managers to look at (mine and Geir Harald Hansen's)
for details, though they're both pretty obscure to
read through.

  Still, you can easily get the basics by reading the
Kernel Library stuff, or something based on it (like
Phantasmal).


=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd