[Xesam] Iteration two, metadata api

[Evgeny Egorochkin]

В сообщении от Thursday 04 December 2008 10:48:21 Philip Van Hoof написал(а):
> The current metadata storage API has a few problems that we discovered
> while implementing the Turtle file support for Tracker.
>
> In a way is inserting metadata via a Turtle file the same thing, with a
> difference being that instead of over IPC the data comes from libraptor.
>
> Nonetheless, we are inserting RDF triples, which is the same as what the
> metadata storage API is promising to service ... over IPC (the feature
> of letting you as an external app insert triples about an existing or
> about a new resource).
>
> For this it was needed that per group of triple that we insert, we know
> the resource's URI, the rdf:type and the File:Modified predicate.
>
> The API as proposed at http://xesam.org/main/XesamMetadataAPI does not
> require that rdf:type and File:Modified are passed as fields.
>
> This means that it would be unimplementable for many Xesam implementers.
> Especially the Xesam implementers using a (decomposed) triple store.
> They'll need the rdf:type to know which table to elect for the insertion
> of the triple.

I see a problem with not having a sanity check here. What is to stop a 
malicious/stupid app from creating several objects with the same uri but 
different content/source? If you implement such a check, you don't really 
need the client app to implicitly specify content/source everytime.

> The File:Modified is needed for collision handling: what if a record
> already exists? How do you know that what is being proposed by the user
> of the XesamMetadataAPI for insertion is more recent than what you
> already had?

This is a very important topic. Concurrent access to the database from several 
clients. So far there's no access arbitration. locking. Again, the most 
reliable timestamp, the one which can't be faked by a broken client app, is 
the system time. Also, perhaps you were considering applications which would 
cache several metadata write requests and would like to put the actual 
timestap on older writes.

We need to seriously consider concurrent access issues.

> For example:
>
> Set (<maildir://folder/UID001>, ["Message:IsRead"], ["True"])
>
> How do you know that the caller of Set is the most recent?
>
> What you need instead is (something like) this:
>
> Set (<maildir://folder/UID001>,
>      "rdf:type", "Message",
>      "Resource:Modified", time(),
>      ["Message:IsRead"], ["True"])
> or
>
> Set (<maildir://folder/UID001>, ["rdf:type", "Message:IsRead"],
>      [time(), "True"]);
>
> But for the last one rdf:type and Message:IsRead would be required
> fields (predicates).
>
>
> Some pointers:
>
> http://live.gnome.org/MetadataOnRemovableDevices
> http://svn.gnome.org/svn/tracker/branches/turtle/