2007/2/20, Joe Shaw <<a href="mailto:joeshaw@novell.com">joeshaw@novell.com</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Indeed, and we should also use the same storage for it whenever possible.  I envision a three-tiered system for actually setting metadata on files: 1. Store the metadata in the file itself whenever possible.  Things like id3 tags in MP3s or XMP metadata in jpegs.  This is ideal because it's in a standardized format that most tools can read, and the metadata follows the file around no matter where it's sent. 2. Store metadata in extended attributes on the file in the file system. This has the benefit in that the metadata follows the data around within a single system, and our desktop applications can be standardized around a schema for xattrs.  Obviously this won't work for non-file items or on file systems that don't support them. 3. Lastly, store metadata in some sort of centralized store, like a sqlite database.  Keeping metadata in sync with data is harder, but fortunately most of the data that would require this mechanism wouldn't have mostly unique URIs.  I'm sure Jamie will disagree with me on this, but I don't think this requires a constantly running daemon; a simply library interface would probably suffice.</blockquote><div> Allow me to pick up on 3. :-) How would you manage locks on the db? Was synchronization issues not the reason why leaftag wasn't successful? I mean if you can't keep file tags synchronized then you are unlikely to succeed in keeping general metadata up to date... Cheers, Mikkel </div> </div>