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

[Kevin Littlejohn <darius connect com au>]

> 
> 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).  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 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 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 guess my next question is - is the metadata best stored next to the file,
where it's not going to get lost if you move directories or shuffle filesystems
from box to box, or is it best stored in a per-user database of some sort,
where we can take a stab at 're-synchronising' the data when it gets muddled
up?

KevinL