Re: Moving away from app-centric mimetypes (e.g. kword)

Steven D'Aprano schrieb:
> 
> On Tue, 14 May 2002 23:58, John Summerfield wrote:
<snip> 
> > > EAs are really fine, but the management of access rights is a
> > > problem, too; especially when you think of shared files. And I am
> > > not shure in how far they
> >
> > How so? Shouldn't EAs have the same access rights as the file?
> 
> There are different views on this. For instance, if I can see the files
> in a directory, shouldn't I be also able to see their metadata? File
> size, file name and modification date are metadata, and I can see them.
> It is silly to require read permission to a file in order to see its
> name!
> 
> But then, there may be some types of metadata that shouldn't be visible
> unless you have read permission.
> 
> Its a difficult question, and there is no easy consistant answer.

Let the owner of a file decide what of his metadata is public available.
For a start.

<snip>
> A broad-based, open-ended metadata system with a rich data-type set and
> flexible API surely requires kernel support, and maybe even a
> completely new database-driven file system, which is not coming in the
> forseeable future (at least for Linux). However, a limited, but still

Didn't some people from mysql start on this?

> useful, subset of metadata can and should be implemented at the KDE
> level.
> 
> Why do I say it *should* be implemented at the KDE level? Because
> metadata is a solution to many problems, and a great help to the user.
> If we wait for the kernel guys to do it, it might not ever happen. By
> implementing a partial solution, we:
> 
> (i) add a useful feature;
> (ii) innovate in an obvious way; and
> (iii) maybe inspire the kernel guys to think about metadata support.
> 
<snip>
> Metadata will be stored in the file's parent directory, perhaps in the
> .directory file. I propose this, not because I think its the best
> solution, but because it is a *reasonable* solution -- its faster than
> using a central database, and KDE already reads the .directory file
> when needed, so KDE isn't doing excessively more work.

or use a ".filesmetadata" directory where files with the same name like
the original one store the metadata.

> The disadvantages are that, if you move or rename a file, you lose the
> metadata. But since this is a Proof Of Concept, and not a perfect
> implementation, perhaps we can live with that limitation in the short
> term.

Most of my renaming and moving of files is done these days in konqueror
so if it has support there should be no loss. And for command line there
could be an alias for "mv" etc that invokes a script doing things that
are nessecary to keep metadata consistent.

So everything that is missing is someone coding it :(

Friedrich