[Tracker] Request for review of writeback branch
- From: Philip Van Hoof <spam pvanhoof be>
- To: tracker-list gnome org
- Subject: [Tracker] Request for review of writeback branch
- Date: Sun, 22 Nov 2009 14:45:02 +0100
Hi guys!
I have rebased the writeback branch so that each commit in it is a ~
sensible one by either me or Carlos.
For now the XMP and the MP3 modules are only made to write back the
title of the document. If you read the code you'll notice that no
fundamental changes are needed to add more such simple fields to the
modules.
You can find the branch here:
http://git.gnome.org/cgit/tracker/log/?h=writeback
How it works from two miles above:
o. A tracker:writeback property is added to the rdfs:Property of fields
that we want to writeback
o. The tracker-store is adapted to emit a Writeback signal in case such
a field changes. The signal passed the known rdf:types of the
resource and its subject.
o. A new program tracker-writeback that listens for this signal is
introduced. It queries for all the fields that are marked as
tracker:writeback and passes the results of that query to the
writeback modules that can deal with one of the rdf:types of the
resource.
o. The module checks for the content-type by itself (I'm only mentioning
this because otherwise people might wonder about this. The
content-type is only useful for resources that are local files, to be
honest. This is why it's not in the Writeback signal of the store).
o. The module locks and unlocks the file, and it signals that the first
next time the subject is to be analyzer it should be ignored by the
miner
o. The miner is adapted to ignore files that are locked. This is not
sufficient because the miner is a queue, and by the time the item is
popped from the queue it's possible that tracker-writeback has
unlocked it already.
o. The miner is adapted to accept subjects that are to be ignored once.
o. It supports both rename() style and update style file updates.
- It ignores deletes while in writeback for the resource
- It does the update query in create when in writeback f/t resource
- It does the update query in move when in writeback f/t resource
- If not ignored it unsets writeback mode for the resource
o. The update query updates contentLastModified, contentLastAccessed,
fileSize and mimeType. These fields should never be marked as
tracker:writeback (else you create an endless loop between
tracker-miner-fs -> tracker-store -> tracker-writeback -> FS ->
FS monitor -> tracker-miner-fs -> tracker-store ... (you get the
point, don't you?)
The fields must be updated because tracker-writeback can cause them
to change (mtime, atime, size and mime-type).
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]