hi zeeshan, there will be no live-queries in the tracker api. it is far from trivial to implement them, and extremely difficult to make it efficiently. the signals per class are a cheap mechanism to simulate that: when you query resources from certain class, you can connect to the signals that can affect you (add, remove, changed subject), and act accordingly on those items instead of run the query again. Now the "changed" signal also contains the modified predicates, to make this even easier.
using these signals, it is possible to simulate live queries on the client side. libqttracker does it (maybe somebody is up to implement this on a glib based library). regards, ivan On 12/6/09, Zeeshan Ali (Khattak) <[email protected]> wrote: > On Fri, Dec 4, 2009 at 11:02 AM, Philip Van Hoof <[email protected]> wrote: >> We are planning to remove this signal from org.fdo.Tracker1.Statistics. >> >> <signal name="Updated"> >> <arg type="aas" name="statistics"/> >> </signal> >> >> You can of course still use the Get method, and you have class signals >> in case you want to know immediately when something that is relevant for >> your application changed. >> >> Are there any objections in the community for this decision? > > None from me. :) That reminds me, wasn't there supposed to be some > API for minimalistic live-query? i-e to get a signal from tracker when > a sparql query of mine is out-date for some reason and I (as app) > should execute the query again. Right now I only see a signal that > tells me about changes to subjects in a particular class. > > -- > Regards, > > Zeeshan Ali (Khattak) > FSF member#5124 > _______________________________________________ > tracker-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/tracker-list > _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
