> In the case of ReiserFS, its got the data, but it isn't searchable. > Worse still, apps must be altered en-mass to notice the FS and take > advantage of it. That's just why the idea of a libmetadata or libmimetype is good. It'd allow the programmer to just talk in terms of metadata, instead of hardwiring FS-specific knowledge into each app. The abstraction provided by the proposed libmetadata/libmimetype will let the user just work, while the library decides whether to use EAs or file-based metadata. > I think it will be sometime before kernels and OSes > stop thinking about files and directories and focus on how users need to > access their data. Consider that the Apple HFS has had metadata forever > and all the apps use it, but an indexer is still need to make Sherlock > work--EAs don't solve many problems. EAs aren't exactly the solution to all problems. They solve a specific, well-understood problem: where to store metadata, securely, atomically, and efficiently. You could ignore EAs and write your own implementation, but rest assured that implementation wouldn't succeed, simply because EA folks 1) have already beaten everyone 2) have a standard 3) have wider deployment than any solution which would be written from today on 4) got it right. A file-based metadata implementation is also needed though, no one is discussing that =). An indexer is still needed, though, and Medusa is very well justified. I see EAs as the defacto storage place for metadata, while MEdusa and Storage fulfill the search and clusters roles. The authoritative information, though, has to be in the EAs, and apps have to write it there, with perhaps file system plugins or Medusa updating the EA data out of in-band metadata for legacy files (e.g. writing the Artist and Album and Song name tags of MP3 I just tagged with an app that doesn't write EAs). That would ease one heck of a lot the implementation of Medusa and STorage, because they'd have only one place to look for the information. -- Manuel Amador (Rudd-O) GPG key ID: 0xC1033CAD at keyserver.net
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente