Re: [Tracker] Roadmap to 0.7

[Jamie McCracken <jamie mccrack googlemail com>]

Sure I understand

But they want us to support Events for file histories so all im saying
is lets make it easy for them to have a more optimal architecture with
tracker. EG if they intend to keep their middleware then lets give them
direct access (assuming that is implemented) for selects. 

If the tracker/zeitgeist thing does not perform well they may revert to
using their own db so its in our interests to help them out here

jamie


On Fri, 2009-07-10 at 14:17 +0100, Martyn Russell wrote:
> On 10/07/09 14:04, Jamie McCracken wrote:
> > On Fri, 2009-07-10 at 14:47 +0200, Philip Van Hoof wrote:
> > > I'm sure that if there are performance issues with Zeitgeist that the
> > > Zeitgeist team will eventually optimize them out.
> > >
> > > For example, indeed, by reimplementing them in a more performing
> > > programming language, or maybe even by implementing them as miner
> > > plugins, SPARQL functions or code running in Tracker's processes.
> > >
> > > I don't believe that Zeitgeist performing badly will affect Tracker's
> > > reputation.
> >
> > putting it in a more performant language wont help as its the
> > architecture thats suspect
> >
> > Here is what is zeitgeist is intending to do so far as i see it:
> >
> >
> > 1) Zeitgeist front end<->  dbus<->  Zeitgeist Daemon<->  dbus<->
> > Tracker
> >
> > 2) Gnome apps<->  dbus<->  Zeitgeist Daemon<->  dbus<->  Tracker
>
> Right but I think it is a bit premature to blame latency issues on DBus 
> before we know what data is being requested. Also applications can cache 
> some of this information if they have to, or do the querying at *more* 
> appropriate times. Also the user won't mind waiting a fraction of a 
> second for things like this in a user interface, they will mind:
>
>   - 100% cpu
>   - not indexing content properly
>   - broken software
>
> Etc. I.e. all the things tracker 0.6 was famous for. No one really 
> mentioned the speed as much as the brokenness.