Re: [Tracker] Storing Metadata with files
- From: Nikolaus Rath <Nikolaus rath org>
- To: Ivan Frade <ivan frade gmail com>
- Cc: tracker-list gnome org
- Subject: Re: [Tracker] Storing Metadata with files
- Date: Tue, 25 May 2010 10:11:17 -0400
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
This is just an idea, feel free to comment,
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?
Personally I really don't care about them. But then, I want to index
dedicated directories that are used exclusively for archiving.
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?
»Time flies like an arrow, fruit flies like a Banana.«
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
] [Thread Prev