2009/7/13 Seif Lotfy <[email protected]>: > Hey guys, > > Before I start I have to make clear that Zeitgeist is not a UI. > Again Zeitgeist is an event logging framework and distributor. We capture > events and make sense of them. > Where we store is not exactly our biggest concern. Comparing Zeitgeist and > Tracker just can not be done. Tracker is a storage and indexer. A UI can be > delivered for both. > > Zeitgeist can make use of information that tracker has. > > Here is what I see doable from Zeitgeist side for the upcoming future: > 1. signal tracker to index items upon activities > 2. pull information about docs from Tracker > 3. start pushing infromation about docs into Tracker > 4. Once an event ontology has been implemented store into tracker (this will > take alooooooooooot of time though) > > In the meantime we will continue with our work and I hope every1 understand > that we cannot refocus a whole team into changing their work. So for now I > will personally try to get the first two points done. > > We can not depend fully on tracker now as long at the GSoC is running. It is > my duty to make sure everyhting gets delivered. > But taking these steps seem to be very reasonable. > > Cheers > Seif > > > 2009/7/13 Natan Yellin <[email protected]> >> >> >> ---------- Forwarded message ---------- >> From: Natan Yellin <[email protected]> >> Date: Fri, Jul 10, 2009 at 4:50 PM >> Subject: Re: [Tracker] Roadmap to 0.7 >> To: [email protected] >> Cc: Philip Van Hoof <[email protected]>, Tracker mailing list >> <[email protected]> >> >> >> Hello, >> >> On Fri, Jul 10, 2009 at 4:04 PM, Jamie McCracken >> <[email protected]> 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 >>> >>> >>> As you can see in that arch, dbus is used twice for everything so you >>> double the latency and cpu needed to copy and route data. This is >>> independent of language used although python being the slowest language >>> around may well exacerbate it further >>> >>> Here is what im proposing by removing the unnecessary middleware : >>> >>> 1) Zeitgeist front end <-> dbus <-> Tracker >>> >>> 2) Gnome apps <-> dbus <-> Tracker >>> >>> bear in mind zeitgeist wants to use tracker for full text searches, >>> searches for tags as well as updates and its these searches which will >>> be delayed by their proposed architecture - that is my concern. If there >>> is stuff that tracker does not or will not do then they can use libs >>> instead of a daemon to avoid the suspect arch as well >>> >>> I also feel the real fun in zeitgeist is surely in the front end >>> zeitgeist timeline based UI they will produce and not back end work >>> which is best left to us IMO >> >> As a Zeitgeist developer, I'd like to clarify something: Our goal is to >> deliver is to deliver a new user interface for managing/browsing documents >> in time for GNOME 3.0. What's extremely important to us is that we release >> early and often enough to receive feedback from the community and polish our >> work. >> >> I don't know what Seif has discussed with the Tracker team at GCDS- and I >> don't speak for all of the Zeitgeist developers- but it really doesn't make >> any difference to me whether Zeitgeist's GUI accesses the database through >> Zeitgeist-Daemon (which itself pulls the information from Tracker) or >> through Tracker itself. What matters to me a lot more than the speed benefit >> are a few things: >> >> 1. A high level API that wraps around SPARQL: I do like the option of >> using SPARQL for advanced queries, but right now we don't need that much >> power and it raises the entry bar for new developers. >> >> 2. A stable D-BUS API that we can use today. (I'm planning on releasing >> some code that I'm working on before Tracker 0.7 is even released.) We can't >> wait for tracker to add support for tracking timestamps and stall all >> development until then. >> >> 3. The ability to quickly write indexers in any language and insert new >> documents into the database over D-BUS: As said above, speed isn't that much >> of a concern at the moment. It definitely makes sense to eventually rewrite >> Python indexers in C to improve the performance, but now is not the time for >> that. Time is a lot more valuable to us then speed. >> >> I'd say that at the moment Zeitgeist front end <-> dbus <-> Zeitgeist >> Daemon <-> dbus <-> Tracker makes sense because we already offer high level >> APIs that applications can use today. I wouldn't mind migrating some of >> Zeitgeist Daemon's functionality to Tracker or a suite of Tracker indexers >> over time, and eventually it may be possible to integrate it into existing >> software and get rid of it entirely. >> >> There's one other major advantage that using Zeitgeist as middleware (for >> now) gives us and that's flexibility. If tomorrow we decide to add on to our >> ontologies (and Events is a good example of this) then we want the ability >> to do it immediately. As GNOME 3 comes closer and our prototypes turn into >> deployable apps, we'll focus on speed and cutting out unecessary steps >> wherever possible. >> >> Regards, >> Natan >> >> > > > _______________________________________________ > tracker-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/tracker-list > >
Hi, Just back from holidays I feel that I have to add my 2 cents to the Zeitgeist debate here. The gist of it is, as both Seif and Natan expressed, "Don't panic". Zeitgeist is (currently) written in Python, and this has proven a good choice because Zeitgeist is in a lot of flux. The core problem is that it is still unclear exactly what Zg will - and should - do. We are in a process of information gathering and learning because this whole field of "desktop event mining" is not really well known (for all I know Seif invented it! :-D). It is my personal ambition to rewrite what ever makes sense in C/Gobject or Vala when the Zeitgeist goal and scope has stabilized. The core achievements of the Zeigeist project is in fact: * Defining an ontology for desktop events (we might also need some extensions to the Nepomuk ontos, but this is not certain) * Defining good DBus API(s?) to handle the logged information * Understand how UIs should be designed to take advantage of the Zg knowledge * Proliferation of event logging in apps The whole architecture implementing support for all of this is an "implementation detail". There's no reason that Tracker couldn't natively expose the Zg API, or that Canonical could write a native Erlang impl. sitting on top of CouchDB if they so desired. The coding to support all of this is the easy part. - Given the two following technical requirements at least: * An indexed data store for log entries/events * An indexed data store for item metadata (tags, comments, rating, etc) Currently we have custom Python+Sqlite underpinnings because it is most convenient in this early hectic development phase. -- Cheers, Mikkel _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
