El mié, 14-01-2004 a las 12:54, Alexander Larsson escribió: > How would such a metadata system work? If it uses a file per file, or > EAs then it would instantly be as slow as sniffing. This assumes a certain, flawed or biased, implementation of EA or XML files, biased against them. The ideal file-based implementation would use one XML file per directory and write locks (making large directory reads for metadata REALLY fast). The ideal EA-based implementation would leave the optimization to the file system (EA-supporting FS implementations already are taking care of this issue) perhaps being even faster than the XML option. I recognize that reading file extensions would be marginally faster (not 400 times) than reading MIME types from an EA store, but the usefulness of the EA store suddenly makes possible to store lots of things for which you previously had to look on other parts of the disk, actually enhancing your possibilities as a developer while keeping the speed to yourself =). > If it used a > metadata system with e.g. one file per directory it could be fast, but > that adds a *lot* of complexity with locking and consistancy handling, The only thing you need to do regarding locking is: lock(metadatafile) do your thing unlock(metadatafile) that's it. You can still use EAs. EAs will also be supported by the GNU file utils and tar and the like, and I sincerely don't think a metadata file would ever be supported by them (other than collaterally). The important issue is: * you can use EAs where they are available, and use file type detection where they aren't - you can leave the details for other people * > file permissions, This issue has been cleverly solved by others. Of course, I know there's no solution for the case of a file-based metadata implementation, but then in those cases you could choose to store only "unclassified" information, such as the MIME type. > and possible out-of-process communication. There has > been thoughs about a common metadata system, but they are far from near > implementation, The Mac has a working, fine metatada implementation. Windows XP and Longhorn both have metadata implementations in the form of streams (Longhorn even has WinFS). The fact that you think no people from the FLOSS camp have tried to implement it doesn't mean it's impossible to do (in fact, people like Hans Reiser - ReiserFS - and Seth Nickell - Storage - have done great advances in the field). > and there are many issues to solve. I don't think so. Of course you're welcome to digress =). > > Additionally a metadata-based system would mean any non-nautilus > operation on the file could make it drop the metadata, I agree on this if you used an XML implementation. This can't happen on an EA file system. > leave metadata > around forever, See previous sentence. > or make the metadata stale. See previous sentence. > It would also have problems > with read-only media and probably other complications. Why would it have problems with read-only media? If the media is read-only, any updates to the metadata store HAVE to fail silently. What's the problem. This sounds like FUD. Sooner or later it will happen: a metadata system will have to emerge, and while it hasn't, it would be wise to take the lead instead of ignoring it. Being leaders ensures continuous attention from the mainstream, helps you become the one that sets the standard, and has other advantages. It's in our hands to be leaders or followers. And it doesn't sound like we're being leaders (see Longhorn). We're still on a time frame to beat Longhorn on a workable, fundamentally correct, functional, fast implementation of a metadata system (by putting at least Storage and EAs together). (I feel that the role of Storage as an additional layer above the file system is a little bit heavy. I'd rather have Storage *cache* the metadata for which the file system is actually the primary source, and update the file system whenever a new file comes into "acquaintance" with Storage. Storage should also have the role to provide APIs to read and write in a standardized way to the metadata store, which ultimately would be the file system, NOT Storage's database. Storing things like file comments, links to people objects, links to mail messages, stuff like that, stuff that will enrich the desktop experience much, much more than wondering whether Nautilus should detect files by content or by type). > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl redhat com alla lysator liu se > He's a bookish soccer-playing werewolf gone bad. She's a strong-willed snooty > safe cracker descended from a line of powerful witches. They fight crime! > > _______________________________________________ > gnome-devel-list mailing list > gnome-devel-list gnome org > http://mail.gnome.org/mailman/listinfo/gnome-devel-list -- 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