Re: [Tracker] Storing Metadata with files
- From: Ivan Frade <ivan frade gmail com>
- To: Martyn Russell <martyn lanedo com>
- Cc: Nikolaus Rath <Nikolaus rath org>, tracker-list gnome org
- Subject: Re: [Tracker] Storing Metadata with files
- Date: Tue, 25 May 2010 11:06:37 +0300
> tracker would be to either extend the XMP sidecars extractor to extractHmm, a new extractor won't work here. To catch ALL files, you would need
> 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?
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,
] [Thread Prev