On 05/25/2010 04:06 AM, Ivan Frade wrote: > I think that the idea of the XMP sidecar file is interesting. Right now > we have the Writeback mechanism to save metadata _inside_ the files. We > all agree that it is not an scalable solution (the amount of > file/metadata formats multiple the combinations). Maybe a writeback to a > sidecar XMP file solves our problem: the data is "with" the file, and we > don't need to deal with the metadata formats. > > I see already a some issues here: > * Conflicts between internal metadata / sidecar metadata > * Space (duplicates the number of files in the filesystem) > * How populated will your file manager look with those "useless" files > * Efficiency: is it quicker to read the metadata from an MP3 or to parse > an XML file? > > I am not 100% sure about the handling of sidecar XMP files in the > miner-fs code, but that is just some implementation work on the tracker > side. > > This is just an idea, feel free to comment,
Space: I think that space is not really an issue. Is there really a case where the metadata grows to more than a fraction of the size of the data file? "Useless files": Personally I really don't care about them. But then, I want to index dedicated directories that are used exclusively for archiving. Conflicts: It seems to be that in the normal case both sidecar and internal metadata are available simultaneosly. So whenever one of them changes, the other one should be updated automatically. Which kind of conflicts do you have in mind? Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C _______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list