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

[David Jeske <jeske home chat net>]

On Sat, Aug 15, 1998 at 11:44:38AM +1000, Kevin Littlejohn wrote:
> > 
> > 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
> 
> I think, by addressing it this way, you're loosing most of your
> audience :) We _don't_ want a per-app or per-filetype resource -
> those sorts of things are easily done (witness KDE, for example).

On the contrary. KDE can't handle multiple versions of the same apps,
nor can it handle me just "moving an app around". In fact, the way KDE
is setup, I can't even install apps where I want them. I can create a
single alternate install location instead of /usr/local/KDE/bin. So,
for example, I could use /usr/local/foo/bar/KDE/bin instead. However,
ALL apps must be installed there, and so I can't separate them at all.

> What's we're specifically aiming for is a _per-file_ ability - so I
> can set 'less' as the viewer for .log files, but 'draw_pretty_graph'
> as the viewer for the /var/log/httpd/access.log file, as an example.
> Incidentally, I've just blown the 'hash' idea out of the water with
> the above example :( *sigh*

I think that straightening out the encapsulation issues (like Nextstep
did) is the first step. They have a heck of alot better 'open this app
for this file' stuff than ANY other system based on UNIX. Then, when
that's working, move on to do the per-file config stuff much like BeOS
does. Then we'd have the best of both world. (i.e. Next's app
encapsulation, BeOS's flexible meta-data)

> I think it comes down to there is no way to keep metadata and not loose it
> if you attack the filesystem with non-GUI tools (eg. mv/cp) (and I'm assuming
> you _don't_ have the ability to LD_PRELOAD all the time here), so whatever
> approach is used has to recognise that and allow for resynchronisation and
> graceful error handling.  Probably also, it needs to be reasonably obvious
> to the user _how_ it breaks - nothing worse than doing something you think
> should work, only to find it doesn't.

I think we should spend time now putting the supports in place so
it'll make sense to have a full metadata system. If we do it now, then
it'll just be a whole lot of /usr/local/bin/unix/paths/suck, stuff,
and there will be metadata layered on top.

> I think maybe it makes more sense to acknowledge that we can't cover the
> non-GUI tools, and code the thing appropriately, than to decide not to cover
> the 'individual file' case.

I think it makes more sense to figure out what we are going to USE
metadata for, put in place the other supporting apps/systems using
existing methods, and then eventually do changes to the filesystem to
support arbitrary metadata. For example, instead of some of the
schemes, presented, I'm advocating that we realize early uses of
metadata will be:

1) to determine the filetype and setup:
   - the app to launch
   - the icon to show
2) to customize this per file

Right now, if this metadata thing was in place, there wouldn't be any
worthwhile, robust system for figuring out what app to launch, even if
I could pull the type information out of metadata. IMO, the existing
stuff in KDE isn't going the right direction, and Gnome dosn't do this
yet. 

I think we should focus on item encapsulation (i.e. app encapsulation)
and coming up with a robust way for apps to export information about
what types they can open. As a first run, we can just use file
extension to map a file to it's filetype. Eventually we can replace
that with a flexible metadata system. However, at least there will be
a decent structure in place for apps to be encapsulated, and for them
to export information to the system about what types they can open.

We _don't_ want to hack out a metadata system, and then have people
start putting in Key/Data pairs like "app_to_open" ->
"/usr/local/Gnome/bin/netscape". That is just the wrong road to go
down.

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