Re: An answer to metadata, complete.

[Leareth <leareth geocities com>]

>1) The icon could be implemented in a other way, for example by having 
>   another file called <filename>.icon, which would BE the icon.
>   No need to make things complicated when there's other, easier,
>   methods.

poluting the file system is, imho a 100% BAD IDEA TM,
	A: It is ugly.
	B: The files are not sync'd in anyway, so it still
	    falls apart if you modify it outside of the control library.
	C: It's slow, each directory you read, you have to over
	    head of checking for a extention files, read them all in,
	    and update them all when you leave the dir.

>2) How do you think the 'smartness' should be implemented? HOW can you
>   store meta-data than can say how the file is to be edited/printed?!?
>   To be really shure, you would have to include the whole editor,
>   printerprogram etc. with each datafile. And that's a waste of space!

You store keypairs, it's a simple database...
	doc /home/leareth/sea.txt {
	default == xemacs
	print == lpr
	edit == gedit
	icon == wave.png
}
Would be an entery in a users database, and whatever is not over ridden in
here, would use the system defaults. (eg, normal mime types or whatever).

>   A much better approach would be to implement a database of different
>   filetypes, and means to recognize files of different filetypes.
>   Ofcourse the filetypes should be configurable (by the administrator).
>
>   And then make an interface with user-defined (possible) actions (for
>   example 'edit', 'print' etc.) for each different filetype.
>   Ie., 'edit' could invoke the editor that can edit that filetype,
>   'print' would envoke a program that can print that filetype, and so
>   on.

Haveing only one central database means that users can define seperate
metadata for single files, not file types, and it still doesn't solve non
metadata awear programs playing with the files, and the database becoming
corupt.

>3) Anyway, it would be very hard to implement support for meta-data 
>   without having support for it in the kernel and filesystem. 
>   If you DO manage to implement it without the support of the kernel
>   and filesystem, it would take quite a lot of resources to keep
>   track of all files and meta-data (figuring out what happened to a
>   file if it isn't by the system, but with a normal command etc.)

Hard yes, but I belive I have done it, and in a very elagent maner.
The databases that I use are very small, keeping track of no data that
isn't 100% nessessary for the goals stated.

--
Leareth <leareth@geocities.com>
-- You've got to lose, to know how to win.