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

On Tuesday 14 May 2002 17:15, Steven D'Aprano wrote:
> 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.

This is defintely the way to go. Oracle inspired this with its Oracle 
8i, and now it going mainstream. Fine with me.

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

I agree with you. We have many tools at hand to perform the task.

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

OK; those are metadata, but the way they are treated does not satisfy 
me. I already hated OS/2 for its approach "let the file system be a 
file system, and store metadata in a database". This was completely 
crap. Sorry.

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

No, please not. This is a quick-and-dirty hack, that would cause severe 
problems later on:

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

Here we go: We have the wonderful concept of ioslaves in KDE. This is 
really great, since all kind of data can be accessed in unified way. 
The first step would be to design an abstraction layer for metadata at 
the ioslave level. This should be done with care, keeping portability 
and extesibility in mind.

I could imagine this similar to the plugin architecture of konqueror: If 
a storage location supports metadata, it is shown in the 
properties/save as/etc. tabs of the dialogs. If not, the tabs are 
greyed out.  Moving a file between locations with different metadata 
capabilities would display a warning, if necessary. At this occasion, 
an abstracted and more complete permission system could be designed.

Then, as a reference implementation, I would suggest an MySQL ioslave, 
storing files as blobs and the properties in a database. These files 
are only accesible by KDE ioslaves, OK -- but this is a good starting 
point. When the filesystems are ready, the file: ioslave could follow, 
and other ioslaves as well. One also has to rethink the concept of a 
hierarchical directory tree and look for useful extensions. Designing 
such a thing "from scratch" is a fascinating task, and it would be cool 
if something like this could run in alpha quality on KDE before M$ gets 
it patented :-). It would be a good idea to look for present research 
in the CS community on the problems.

This way, the design of the (future) meta data abstraction layer is in 
no way limited by the capabilities of todays filesystems. For me it 
would be the cleanest way to approach the problem. For the future of 
KDE and Linux distributions, the "Desktop" and "Documents" folders 
could be stored in an MySQL database. In a corporate setting with a 
multiuser database server, this could be an immense productivity boost 
if I can use database queries to locate documents. It would e. g. be 
possible to create different tree structures containing the same files 
(which is similar to hard links on a UNIX filesystem).

If someone is really cool, one could also imagine to write an VFS 
implementation for the SQL protocol, allowing access to the files for 
_any_ Linux application on the kernel level. IMHO this has already been 
done for FTP or http servers, so it is not an impossible task. 

So far my ideas on extended attributs and storage systems of the future,

Sven.
-- 
I don't have an email address. I reached an age where my main
purpose is not to receive messages. (Umberto Eco)