Re: An answer to metadata, complete.

[Adam Chodorowski <archmage earthdome com>]

> I belive you hit the nail on the head fairly well.
> I was proposeing a way of makeing each file "smart",
> in the sence that it ha sit's own icon(over rideable from it doctype default),
> has a way of printing itself, opening itself, and editing itself, all user
> modifyable. and that the database that controls all this is user unique,
> and does not lose track of files modifyed by programs that are not awear
> of the extended data.

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.

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

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.)
 
-- 
Adam Chodorowski (archmage@earthdome.com)