Re: [Tracker] questions

[Jamie McCracken <jamiemcc blueyonder co uk>]

Samuel Cormier-Iijima wrote:
> On 9/15/06, Jamie McCracken <jamiemcc blueyonder co uk> wrote:
> > Our dbus connection uses the main thread's mainloop where we place
> > incoming request on an async queue which can be serviced by multiple
> > threads from a threadpool.
> >
> > When tracker becomes popular and is used by more third party apps  we
> > will need more than one thread here to handle concurrent requests in a
> > timely manner.
> >
> > I am not sure how what you say can help here but feel free to prove
> > otherwise. (you woulkd only have one connection/thread with your
> > suggestion?)
>
> Of course, the rationale I had in mind for using GObjects was not
> performance, but cleaner and easier to maintain code (with relatively
> little lost performance). If you're planning on Tracker becoming the
> backend for things such as music players (i.e., display all their
> music just through Tracker queries), I would argue that perhaps DBus
> isn't the best infrastructure for that... If I recall correctly, DBus
> has a 64 Mb limit for data sent over the bus, and currently my index
> is at about 25 Mb... performance would probably be worse than a custom
> coded Unix socket IPC solution.

It shouldn't be a problem in practice as results can be paged (offset 
and max_hits parameters). Very few (or rather badly writtem) apps would 
want to download everything in one go.

Client/server database apps (and tracker is one of these) are designed 
to give data to clients on a need to know basis. For rhythmbox and other 
music databses the ideal scenario  is to query tracker's database 
instead of downloading all music uri's into its own propriety database. 
For an email app, it would simply get results from tracker in lumps as a 
user scrolls up/down - there really is not a need to download 
everything. (if there were ever a case where it did need to get 
everything then using sqlite directly would make more sense)

When used correctly these clients have excellent performance and minimal 
resource usage as socket traffic is reduced to negligible amounts.

> >   also,
> > > on that note, like you said, it might be a good idea to get some unit
> > > tests into tracker. i've been coding up some "stress tests" python
> > > scripts, and can send them if you'd like.
> >
> > yes please that would help more than coding the above in gobjects.
>
> i have class right now but will look into it


great thanks.

--
Mr Jamie McCracken
http://jamiemcc.livejournal.com/