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.
Hmm, this seems like a kind of heavy way to implement live queries. Clients basically have to rerun the query in a polling fashion everything anything changes, pulling down all the data again.
I guess if you just want to display “last 10 emails” its ok, but that sort of usecase seems pretty limited.
@alexander:
Well, the fact is that for live query support the server would anyway need to run the same query, but in addition, also the server would need to keep the session alive for the live query so that the change damage map can be properly calculated, so processing wise, this is probably better solution, as application can at least now decide when it needs to refresh the content. Also, any removals are really easy for the app to do, and so are changes (you can just re-query the changed content). Additions tend to require a bit more logic if the sorting is done on server side. If the sorting is done client side, even the additions are easy to do (you just rerun the same query again with the additional filter that it only applies to the added items).
Holaaaaaaaaaaaaaaaa