> The big thing is to really not depend on the presence/support of
> metadata. Here it goes. You have file and its metadata. You transfer
> over net using metadata-unaware program/system. Metadata
> lost. Application opens file. No problem. User edits file, perhaps.
> User hits save. Application realizes there is no metadata.
> Application writes metadata. No problem.
> Sure. But in that case, exactly what are you going to be storing in the
> metadata? It has to be information which is can be rederived from the
> main data fork. But in that case, why not just use the information from
> the main data fork and be done with it?
Since some information could not be rederived from main data fork FAST.
For example you could use 'file' command to obtain infromation about file
type or similar command to get MIME type of file contents but both operations
are not trivial (and could produce wrong results sometimes). Or we could
keep there preview verions of JPEG's or GIF's. If this information is lost
it could be recovered but this will require A LOF OF processor time. What
about per-user metadata... This could be good idea also but in this case there
are a lot of problems -- what to send over metadata-aware ftp ?
> My point was precisely this --- if you restrict yourself to data for
> which it is harmless if the metadata disappears, then there generally
> isn't very useful for the application. There might be a few specialized
> uses for it, but is it really worth all of this effort for a rather
> marginalized uses?
For now we could use this for web-server's: if metadata contains information
about MIME type -- use it; if not -- try to use mod_mime, mod_magic, etc as
usual. You could put PGP signature there -- if you lost PGP signature with
file transition this will not be disaster even if this is essentional
information... When [and if] metadata will be standard (not in this century
anyway :-) and will be used everywhere in in NET it's could be possible to use
metadata for more essentional information as well.
> For the desktop, if you want to store information about where on the
> screen the icon should live, then perhaps that would be a valid use of
> metadata --- but that's a desktop use, not an application use.
> But as Alan Cox has pointed out, information about what icon to use, and
> where on the desktop the icon should live, or even which application to
> use when opening a file (emacs or vi?!?), etc. really should be stored
> on a per-user basis. Furthermore, the user should be able to modify or
> store this information for files for which the user doesn't have write
> access. You also don't want to have different users being able to
> modify this information for other users. All of this means that it's
> probably best to store all of this information in a central database or
> dotfile in the user's home directory.
We need at least link to this database in metadata infromation :-) So renaming
of file will not broke their link to emacs or vi ... Not clear what to do with
file deletion or copying :-((
> So it's not clear that file metadata would be useful for desktop
> systems, either!
> This brings me back to my first observation --- it's not at all clear
> how useful file metadata really is. Could one of the advocates of file
> metadata give me an actual proposed application which could profitably
> use it?
Yes. Apache is example. If you'll put information about MIME type (language,
charset used for encoding, compression type, etc -- all thing what for now
Apache tries to find with mod_mime usage :-) in metadata Apache (with
mod_metadata of course :-) will use it. If not -- then mod_mime or mod_magic
will be used... The same with e-mail agents...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html