Re: GNUstep directory layout

[Tim Harrison]

Dennis Leeuw wrote:

> That might be an option too. But I don't see any argument for not moving
> DocumentTemplates into the Documentation directory. I guess Documentation and
> Documentation/Templates is clearer, then Documentation and DocumentTemplates on
> the same level. Next to that document templates are actual documents, but I
> think I said that before... ;-)

As I mentioned in my previous message, the $/Documentation directory is 
where documentation lives, not just "documents".  A letter I'm writing 
to my friend in Toronto is a document, but it shouldn't be stored in the 
/Documentation directory.  The file AutoDocTemplate.gsdoc is a document, 
in one way, but it is not *Documentation*.  If there was a man page, or 
an html file, or somesuch that described how the AutoDocTemplate.gsdoc 
template worked, *that* I would expect to find in the $/Documentation 
directory.

Doc[ument]Templates should most likely reside in a /Templates directory 
($/Library/Templates?), where one could find templates for all manners 
of things on the system

> So I guess we agree on this. The should be a /Local/Users (nor argueing on the
> amount of accounts that should be present there) and /Network should be kept
> clean so a sysadmin can decide how to populate /Network.

Actually, I may not have been as clear as I could have been.  We 
*disagree* on the /Local/Users scenario.  I believe that /Users, or, on 
an existing non-GNUstep-integrated system, /home should be the location 
of users who are local to the box.

/Network should definitely be kept clean, but it sounds like you propose 
removing everything from there.  If the admin wishes to modify 
directories within /Network, would that not require patching GNUstep?  I 
would rather see the /Network/Servers, /Network/Users, and 
/Network/Applications remain "official" until a better way for managing 
NFS mounted GNUstep applications or user directories could be found.

> While I write this I can almost hear Nicola scream with terror. How should he
> implement this in his make files. How do we need to search the /Network
> architecture without too much overhead for e.g. applications to run.

I can sympathise. :)  However, if we can work out a way that works best, 
 then it might save some future changes to and fro.

> I think a little config file is needed for that. Like an entry in the defaults
> db where a sysadmin can tell to the system what the search paths are and that
> GNUstep.sh/.csh can use to set $PATH or something like that.

Defaults doesn't sound too bad, but that, I think, is a discussion for 
the more code-oriented folk on the list.

> Yep. I understand the confusion. But I am afraight that Servers will add to this
> confusion, when is something a server. is X11 a server or is it a client. A
> Tool, a App or a Server.

Well, I see X11 as a server, and the applications that run on that 
server as clients.  Hence the common monikers of "X server" and "X 
client".  To me, a server provides access to data, while a tool is used 
to gain access to data, or to modify data.  One gives, and one receives 
or manipulates on behalf of the user.

> The split between App and Tool is not a clear one but gives the user an idea
> what he might expect and probably what is expected from him/her. For Tools he
> needs to get to the console, for Apps he can say in his save graphical
> interface. It's all about user perspective, not if it is technically or
> syntactically right.

The problem with perspective is that everyone has one. :)  If we name or 
organise things by perspective, no one will agree, I'm sure. :)

To throw an OS X wrench into the works, there's also "utilities".  This 
is an organisational grouping under the Applications directory in OS X, 
where things like Disk Copy, CPU Monitor, and Audio MIDI Setup reside 
(can you tell I'm casting a glance at my Jaguar box? ;))

> I know that document :-) But is that the GNUstep vision. Is that what Adam or
> any of the other developers mean?

Well, I think the point is that we're trying to work out *what* the 
GNUstep vision is.  I'm not saying that the GNUstep developers agree 
with Martin's descriptions.  That's why it was a proposal.  If they were 
to agree with  what's written, then that could be the "official" 
description.  As I've frequently explained to many people in many 
different forums and venues, we're not trying to force GNUstep to do 
*anything*.  We merely put together a (rather lengthy -- man, was I 
tired of documentation after doing the GSFH and LSFH proposals :)) 
document to help clarify some structures, and suggest modifications that 
we felt would be beneficial.  I couldn't find, and no one could provide 
me with, documentation on why things were done the way they were.  So, I 
thought it would be helpful if we did some of that work.  And, as I said 
when I originally posted it, if no one likes it, that's fine.  However, 
having developer documentation is a real bonus.  It was just our little 
way of trying to help the project out (and because I'm a notoriously bad 
developer, documentation is the only thing I could offer, myself ;)).

> I completely agree. It was just meant as an idea for someone that tries to build
> a complete GNUstep system.

Being in the process of doing just that, I still think that the Users 
domain should reside outside of the Local domain.

> For me it is quite simple. I have my normal users use /home/<username> and those
> that want to use GNUstep get /usr/GNUstep/Local/Users/<username> as their home,
> and yes I adjust /etc/passwd for that, or actually an adjusted adduser script
> does that for me :-)

Then you get two different places for local users.  That becomes 
confusing in a large environment.  I just migrated a school district 
from Windows 2000/NT and AS/400 to Linux and a few Windows 2000 servers 
-- having users in different places, even on the same box, in a large 
environment is a nightmare :).  Knowing my local users reside in /Users, 
and my network users reside in /Network/Users (or 
/Network/Servers/<servername>/Users) is much easier than having some in 
/Users, some in /Local/Users, some in /Network/Users, and some in 
/Network/Servers/<servername>/Users.

Of course, on non-GNUstep or non-LinuxSTEP machines, I put my local 
users in /export/home and remote users in /export/<servername>/home, but 
that's just because I spent way too much time with Solaris. :)


--

Tim Harrison
tim@linuxstep.org
http://www.linuxstep.org/