[DGD] Methodology: Directory structure & Areas

[Stephen Schmidt]

On Fri, 17 Oct 2003 nihilxaos at nihilxaos.com wrote:
> I take it any such object that does file manipulation (epsecially
> data files) should reside in /usr/System or at least have to call a /usr/System
> object in order to perform the actual writes?

The former seems to me to impose a large and unreasonable burden
on file organization. There are many different types of files which,
for one reason or another, need to write a file occasionally, and
it seems forced to require that they all be in /usr/System, when
they might well be logically grouped elsewhere. For example, the
delete file command should surely be in /cmds or whatever you
care to call it. You can have a /cmds for the commands that don't
write files and a /usr/System/cmds for the ones that do, but that's
what I mean by "forced". I also have a strong dislike for paths
more than about three directories deep, as anyone who's looked at
Melville will have deduced.

I like the idea of having a daemon object which does all file access
sitting in /usr/System, and then having /cmds/wizard/delete.c call
into that daemon object to have the actual delete performed.

Or, from what Noah wrote:

Noah Gibbs <noah_gibbs at yahoo.com> wrote:
> > I get around it by
> > having access-controlled functions in /usr/System that
> > do stuff that requires more privilege.  Since code
> > outside of /usr/ has no user directly associated with
> > it, you need to either have it use only things with no
> > permission controls, or have functions somewhere under
> > /usr/ that recognize that code specifically.

I gather one can write an access manager that would temporarily
grant permission to /cmds/wizard/delete.c to do the file access?

Is that a fair paraphrase of what Noah said? Or is there some
distinction between what I said and what he said that matters?

Steve


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