Re: [Tracker] Roadmap to 0.7

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


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

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<->

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]