Ivan Frade already blogged this, so that that means that I can keep this one shorter.
But yeah, we have just finished what we decided to call class-signals for Tracker. You are looking at software development taking place as we speak, because we still need to do a peer-review of the branch and then merge it to our experimental branch. This will probably happen in a few minutes.
The new feature means that if the ontology of a rdfs:Class contains a rdfs:Property tracker:notify that is set to true, then Tracker will offer a DBus object for that class. Whenever a subject of that class is added, updated or removed you will receive a signal about it on that DBus object.
Ok, ok, I know. You don’t want to click links and search for it yourself. Here are some “screenshots”:
nmo:FeedMessage a rdfs:Class ;
tracker:notify true ;
rdfs:subClassOf nmo:Message .
The DBus API is split per rdfs:Class. That’s because we don’t want that a lot of applications will be listening for each and every change to each and every subject. Now they can instead select the classes that they are interested in. That way they can avoid getting woken up constantly by our damn signal.
This feature is a change signal mechanism. We will eventually implement support for full live-queries.
Supporting full live-queries means that we’ll need to store some state about your session to test whether your SPARQL query requires an update from Tracker to get your client’s previous result list synchronized. It’s quite a bit more tricky, especially if you want to support most of SPARQL to go together with the live-query notifications, and especially if you want to be accurate.
Finally you don’t want the live-query capability to be a huge performance burden each time material becomes updated.
This is why we are now putting in place this feature. We think that for 90% of the applications the capabilities of the class-signals feature will be sufficient for their live update needs.