Re: [Tracker] Live queries

[Adrien Bustany <abustany gnome org>]

Well your point is valid in the sense that GraphUpdated will cause a
process wakeup even if it concerns a completely "unrelevant" update. 
The
fact of determining if the update is "interesting" to the client app is
not CPU consuming, it's basically just checking any of the fields of 
the
structures passed in GraphUpdated against a set of integers (for
example, if I'm only interested in updates on birthdays for contacts, 
at
startup I'll lookup the tracker:id of nco:birhtDate, and then skip any
GraphUpdated where the predicate ID is not the one of nco:birthDate).

One could imagine a system where the client app would register against
the store, telling it "notify me for changes on properties X Y Z", I
however can't tell you if this was already considered. I know
GraphUpdated changed several times, mostly for performance reasons,
Philip might be able to tell your more about the reasons of the current
design.

Cheers

Adrien

On 28.08.2011 22:55, Anders Feder wrote:
> My first instinct was that performance would be better if the IPC
> layer could be skipped, yes. But perhaps the advantage is negligible?
> One case I can think of is if there is spike in inserts/deletes _not_
> matching any registered live query. If using GraphUpdated, then each
> of these will have to go through IPC to be checked by my
> implementation, even though none of them will lead to any useful
> action. This seems wasteful (2 redundant context switches etc. per
> insert/delete), but I am not familiar enough with neither Tracker nor
> D-BUS to determine if this is likely to have much impact in practice.
>
>  Anders Feder
>
>  Den 28-08-2011 20:24, Adrien Bustany skrev:
>
> > Writeback and GraphUpdated are actually not that different, in the
> > sense that they both signal updates to the outer world. They also
> > both
> > apply to only certain statements (filtered with tracker:notify for
> > GraphUpdated, and tracker:writeback for writeback). One difference
> > between GraphUpdated and the writeback signal is that GraphUpdated
> > signals are batched together (for performance reasons), so it's not
> > exactly real time.
> > What exactly are you missing with GraphUpdated? The fact that it
> > involves IPC?
> >
> > Cheers
> >
> > Adrien
> >
> > Le Sun, 28 Aug 2011 12:00:07 +0200,
> > Anders Feder [8] a Ãcrit :
> >
> > > Thanks. While studying the GraphUpdated interface, I stumbled upon
> > > the writeback feature. Apparently, it does essentially the
> > > equivalent
> > > of a live query: it populates a hash table with predicates to
> > > watch
> > > and takes an action every time data using one of these predicates
> > > is
> > > inserted or deleted in the store.
> > >
> > > Would it make sense, then, to make a more generic "stuff to watch"
> > >
> > > mechanism that can be used by both writeback and live queries?
> > > Would
> > > such a solution have any chance of being accepted into the main
> > > source tree?
> > >
> > > Anders Feder
> > >
> > > On 27-08-2011 13:02, Adrien Bustany wrote:
> > >
> > > > Hi Anders
> > > >
> > > > you might be interested in
>
> https://maemo.gitorious.org/maemo-af/libqtsparql-tracker/trees/master/src/live
> > > [7]
> > > ,
> > >
> > > > which is "live query" implementation on top of qsparql, Qt's
> > > > library to access Tracker (and other RDF stores). I've never
> > > > used
> > > > myself, but it's used in several places in the Harmattan
> > > > operating
> > > > system, so it must be working somehow ;)
> > > > If you were to start your own implementation (for example, GLib
> > > > based), I'd guess it'd sit on top of libtracker-sparql and the
> > > > DBus
> > > > GraphUpdated signal...
> > > >
> > > > Cheers
> > > >
> > > > Adrien
> > > >
> > > > Le Sat, 27 Aug 2011 00:00:44 +0200,
> > > > Anders Feder [6] a Ãcrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > So, I finally managed to compile from source. I noted that in
> > > > > your
> > > > > wiki you list "live queries" / "views" as a thing you would
> > > > > like to
> > > > > implement in the future. I too am interested in such a
> > > > > feature, and
> > > > > was wondering if anyone could please me give some pointers as
> > > > > to
> > > > > how I might go about working on this item? I.e. where in the
> > > > > codebase would you add this functionality, are there any other
> > > > > changes that must be made first, etc. Thanks,
> > > > >
> > > > > Anders Feder
> > > > >
> > > > > lÃr, 07 05 2011 kl. 23:49 +0300, skrev Ivan Frade:
> > > > > hi,
> > > > >
> > > > > > it could be that you don't have the introspection.m4 file?
> > > > > > check
> > > > > > that you have the gobject-introspection packages installed.
> > > > > > then
> > > > > > try to start from scratch, with git clean -dfx (beware this
> > > > > > will
> > > > > > remove any file that you have added!) and the usual
> > > > > > autogen.sh and
> > > > > > make.
> > > > > >
> > > > > > hope this helps,
> > > > > >
> > > > > > ivan.
> > > > > >
> > > > > > On 5/7/11, Anders Feder [1] wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > When trying to build the latest version of Tracker from
> > > > > > > git on
> > > > > > > Ubuntu 11.04, I get the following error:
> > > > > > >
> > > > > > > autoreconf: running: automake --add-missing --copy
> > > > > > > --force-missing src/libtracker-extract/Makefile.am:76:
> > > > > > > HAVE_INTROSPECTION does not appear in AM_CONDITIONAL
> > > > > > > src/libtracker-extract/Makefile.am:77:
> > > > > > > INTROSPECTION_CFLAGS must
> > > > > > > be set with `=' before using `+='
> > > > > > > src/libtracker-miner/Makefile.am:149: HAVE_INTROSPECTION
> > > > > > > does not
> > > > >
> > > > > appear
> > > > >
> > > > > > > in AM_CONDITIONAL
> > > > > > > src/libtracker-miner/Makefile.am:150: INTROSPECTION_CFLAGS
> > > > > > > must
> > > > > > > be set with `=' before using `+='
> > > > > > > src/libtracker-sparql/Makefile.am:82: HAVE_INTROSPECTION
> > > > > > > does not
> > > > >
> > > > > appear