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

On Tue, 14 May 2002 23:58, John Summerfield wrote:
> > Am Dienstag 14 Mai 2002 15:37 schrieb John Summerfield:
> > > Move the disk to another computer, all that information goes with
> > > it.
> >
> > Okay, but: Sending the file via email, and the information is lost,
> > isn't it?
>
> So? Of course it's lost if you don't send the metadata. But, you pack
> it up with GNU tar on OS/2 and sent that, and the metadata goes too.

In an ideal word, metadata shouldn't be treated any different from 
data. To the user, metadata isn't metadata, its just *data*. When a 
user emails a file, you don't expect the user to seperately select each 
file fragment on the disk in order to send all the information. 
Similarly, you shouldn't expect the user to have to select the file 
"data" and the file "metadata" in order to send all the information.

After all, if I snail-mail a "recipe" to my mum, I don't expect it to 
stop being a recipe. So if I email a "recipe", it shouldn't stop being 
a recipe either.

Unfortunately, without kernel support, I can't see any practical method 
for associating metadata with a file in a way that is 100% transparent 
to the user.


> > 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.

> > are implemented in the kernel and what about poratbility.
>
> I think some Linux filesystems do implement EAs now. Certainly
> there's been work on it.

As far as I know, there has been work done, but nothing conclusive. 
Apple had the beginnings of an excellent metadata system, although it 
did only have a fairly limited set of metadata types. At least that was 
the case up to OS 9. With the change to OS X, I'm not sure what the 
situation is now.

Microsoft has announced that their next generation of OS (Win3000?) 
will be based on database technology instead of a traditional file 
system. That should give metadata as a freebie.

> > However, I am against an implementation in KDE since this is
> > definitly stuff that should be done on the OS level.
>
> On that we agree.

You might, but I don't.

We had a long and pointless discussion about metadata last year on this 
list, and the final conclusion was that nobody was prepared to make any 
sort of conclusion. So let me stick my neck out and put it on the 
chopping block, and make a bold statement:


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 
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.

KDE already implements a very limited sort of metadata: directories 
have metadata such as "View Properties" and icons, and the Desktop has 
"IconPosition" metadata for any files in that directory. Rather than 
try to invent an open-ended metadata system, perhaps what we need is to 
take baby-steps first, a sort of "proof of concept" that it works and 
is useful.

So I propose that we add a "Kind" metadata to every file. There should 
be an app that lets the user create new "Kinds" (like letter, recipe, 
map, baby picture, project file, crap my boss wants me to do, etc), 
delete them, rename them. Files only have a "Kind" when the user 
explicitly sets one.

"Kind" is not a file type or MIME type. A text file is still text, 
regardless of whether it is an "Instructions" Kind, or a "Letter" Kind, 
or a "Recipe" Kind.

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.

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.

Comments?



-- 
Steven D'Aprano