Hi, On Tue, May 25, 2010 at 11:18 AM, Florent Viard <fvi...@lacie.com> wrote:
> Hi, > > The idea of the sidecar is interesting I think, maybe only one xml file > sidecar per directory is enough? > Could be a first optimization. Still the cost of opening/modify/save that file for directories with a lot of files can be very big. We need also to take into account removable devices (not sure if it is an issue). Regards, Ivan > > ++ > > Florent Viard > Software Development Engineer > ........................................fvi...@lacie.comwww.lacie.com > > > Le 25/05/2010 10:06, Ivan Frade a écrit : > > hi, > > > > tracker would be to either extend the XMP sidecars extractor to extract >> > more information, or to add an entirely new extractor that reads a >> > tracker-specific separate metadata file. But maybe there also an >> > entirely different way to achieve what I want? >> >> Hmm, a new extractor won't work here. To catch ALL files, you would need >> to write a generic one and generic extractors are fallbacks for specific >> ones at this point. >> >> Also, the extractor only gets the metadata for that file format, it >> doesn't extract or insert the file metadata (size, name, etc). So we >> would have to provide some solution for you to do this properly. I don't >> think it makes sense either. This would mean much data duplication in >> user space and that should be avoided where possible. >> > > 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, > > Regards, > > Ivan > > > _______________________________________________ > tracker-list mailing list > tracker-l...@gnome.orghttp://mail.gnome.org/mailman/listinfo/tracker-list > > > *This e-mail and any attachment are confidential and intended solely for > the use of the individual to whom it is addressed. If you are not the > intended recipient, please telephone or email the sender and delete this > message and any attachment from your system. Unauthorized publication, use, > dissemination, forwarding, printing or copying of this e-mail and its > associated attachments is strictly prohibited.* > > _______________________________________________ > tracker-list mailing list > tracker-list@gnome.org > http://mail.gnome.org/mailman/listinfo/tracker-list > >
_______________________________________________ tracker-list mailing list tracker-list@gnome.org http://mail.gnome.org/mailman/listinfo/tracker-list
