Re: [Summary] Meta-data/filesystem-encapsulation

[David Jeske <jeske home chat net>]

On Fri, Aug 14, 1998 at 03:16:18PM -0500, John R Sheets wrote:
> David Jeske wrote:
> > 
> 
> Sounds good to me!  I'm beginning to like the Next system.  Just
> have one question/concern right now:
> 
> > 3) by requiring apps to use relative paths to get to their components,
> >    we allow administrators to have control over where apps are installed.
> >    In addition to other issues, this allows things like:
> >     - user installing apps in their own directories
> >     - multiple versions of the same app
> >     - pre-compiled binaries to be installed anywhere
> 
> How does this work with multiple users?  If you keep all your
> type info in the same directory as the executable, how can you
> change the configuration between users?  You'd pretty much have
> to put each user's personal settings in separate subdirectories
> of the main encapsulated directory.  That doesn't sound like a
> good way to go.

You don't. Only information shipped with the application is stored in
the app directory. Other information is stored in the 'type/icon/app
server' (my name). In NeXT it's stored by the workspace manager.

> Either that, or split the configs up.  The system defaults would
> appear in the app's atomic directory, and if a user wanted to
> override something, they would put something in their
> ~/.gnome/<whatever> directory.  Right?  But then you no longer
> get the "move it and it just works" thing, because you'd have to
> worry about what's in the user's home directory, too.

I would suggest doing what you say. You want to setup icons based on
filetypes in some registry. So for example, there would be an API to
'add this icon for this mime/type" and a Gnome UI would talk to that
API. That api would write some file somewhere.. but it dosn't matter
where, and NOBODY should be touching that file except the shlib which
implements that code.

It dosn't matter where you move the file, because the icons are based
on file type.  You can't have an individual icon for an individual file.

> How does NeXT handle this part?

It does exactly what I said above. It has a "~/.NextDefaults" which
stores informtion in a binary database. You use a shlib API to access
that data. You can create a ".dir.tiff" file inside any directory to
give it an icon, but there can only be one.

In this system, (to keep it simple) we can't change icons for
individual files until we later have some complex meta-data system,
which we're admitting is too much of a change right now. :)

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net