discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep filesystem spec


From: Richard Frith-Macdonald
Subject: Re: GNUstep filesystem spec
Date: Fri, 4 Oct 2002 12:37:54 +0100

On Friday, October 4, 2002, at 12:24  pm, Nicola Pero wrote:


There was some discussion about the Network domain on the list,
although perhaps it wasn't definitive.

Also, this is how NeXTStep and MacOSX did it, not that that is
definitive either.

I don't think NeXTstep did or MacOS-X does it that way.  My
recollection is that NeXTstep had two
separate network areas ... one where remote servers/users are
available, and one (primarily for
diskless workstations) where a master server is mounted to provide
libraries, apps and other resources.

Only the second of these areas makes sense as a 'domain' where we
search for things.

I see no problem with combining the two areas into one ... except that
it needs to be very
clear that the servers and users are *NOT* in the domain in the sense
that they won't be searched
to locate apps etc.

Yes ... I agree with you with the two areas, but I'm still not convinced
by combining them into one.

The two areas have radically different access policies:

* the whole GNUSTEP_NETWORK_ROOT is supposed to be mounted entirely from
a single master server, be writable by superuser only

 * servers and users follow a completely different policy ... possibly
mounted from many remote machines, may contain directories writable by
users

Why not just put them elsewhere ? When designing a filesystem structure,
we want to intelligently and neatly separate areas requiring different
access/permission policies.


My other main objection is ... I'm not really sure why are we specifying where remote filesystems and remote home dirs are supposed to be mounted.
GNUstep works perfectly well no matter where you mount them, and it's
dependent a lot on the system you are working on.

I think Windows for example has his own idea of where to mount stuff from
remote machines, and puts remotely mounted stuff by default in some
standard path (at least, that's the vague idea I got by looking my father
working on his Windows machine) ... well it's Ok for us, who cares, you
don't need to mess up your Windows to mount everything in a GNUstep
directory just to have GNUstep running.

So, while it's compulsory that you mount the master server GNUstep area in
the GNUstep network domain area (because otherwise GNUstep libraries,
applications, tools, bundles etc provided by the master server can't be
found), you can mount user directories (or remote server filesystems, or
your floppy/cdrom filesystem) where you want, likely where it best fits
with your platform ... often your platform/operating system will already
have a suggested choice for where to put them.  If your platform is a
GNUstep-based distribution, then it might make sense to mount this stuff
into a GNUstep directory; if not, it probably makes a lot more sense to
mount stuff where the operating system/user/tradition is mounting it by
default.

Maybe the document is derived from a specification for the filesystem for a GNUstep-based distribution ... which is why it specifies where you are supposed to mount remote stuff - in the process of adapting the document
to be a more general GNUstep filesystem description, we should drop all
stuff which doesn't apply equally well to all systems and platforms on
which GNUstep is supposed to run.

Actually ... I agree with you on all points above.

When I said 'I see no problem' ... what I meant was just that.
If other people want to document a preferred layout for where things
are mounted, this does not seem to me to present any real technical
difficulties. Nothing in GNUstep uses the server/user mounts, so they
just don't matter.

I consider the mounting of other servers and users as irrelevant to the
network domain ... my personal feeling is that it would be better to
keep the two areas separate (to avoid any confusion) but I don't think
it's a very important issue.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]