On Wed, Aug 19, 2009 at 2:53 PM, Ivan Frade<ivan.fr...@gmail.com> wrote: > Hi, > > On Wed, Aug 19, 2009 at 2:11 AM, Thomas H.P. Andersen <pho...@gmail.com> > wrote: >> >> On Tue, Aug 18, 2009 at 22:48, Matthias Clasen<matthias.cla...@gmail.com> >> wrote: >> > I think this recent discussion about tracker as a gnome module is >> > somewhat backwards. I don't think it is leading us anywhere to talk >> > about ontologies and rdf and events and timelines and metadata stores >> > and kernel apis before we answer the first question: >> > >> > What is the user problem that we are solving here ? >> > Can that be described in a paragraph ? >> > And if it can, is it something that a 'regular' user would recognize >> > as a problem he has on his computer ? > > The basic problem is to "link information" and make it available out of the > application silos. The desktop is full of data, but there is no way to mix > those data. IM messaging, Contacts, Email, are very close to each other but > we cannot build a "Google wave"-like window. > > The classic search engines (tracker 0.6, beagle) were fighting against tons > of formats to reconstruct information. The application knows that some > information is a contact, save it in a vcard, tracker reads the vcard and > tries to reconstruct the contact. This solution tends to fail: the > reconstruction is never complete, and a lot of guess is needed. > > So the new approach in tracker 0.7 is to offer a common schema, and let the > application push the information directly. Skip the file step, so no > information is lose in the "file roundtrip". > > What does this mean to the user? That he can see related information > everywhere. > > For instance, take EOG > * you could filter by "photos sent by..." > * you could open an IM conversation with the person who sent you the picture > * you could have a tag cloud, including your fspot tags > * If zeitgeist set relations between photos, it could suggest "related > documents" > * In EOG you can ask for photos tagged as "GCDS" and find > local/flickr/facebook results with that tag > > This could apply also to totem or rhythmbox. s/pictures/songs/ > > The browser: > * Bookmark a page in epiphany, and it is available in firefox. > > Other example: > * Somebody write: "Hey, have you take a look to the document i sent you > yesterday?" and your dashboard shows the last document sent by that contact > and his last blog posts. It can show that not because it understand the > "have you take a look..." but because it knows you are talking with a > certain contact. I.E. No magic or wonderfull inference: just queries to a > well structured database. > > Right now, all the information is already available somewhere (evo, > telepathy, pidgin, ...), but these use cases are impossible to implement. >
Thanks for this explanation - its one of the best ones i've read :) > >> Once we have the problem scoped out, we need to look at the user >> experience we want to aim for in solving it. Will it be a single >> search-for-everything dialog ? A query language ? Tagging everywhere ? > The "dedicated search window" is dead. The applications are the client of > this central storage: the application knows what is showing, so knows what > can be related with it! > >> After that, it might be possible to evaluate whether tracker, >> zeitgeist, couchdb or something else can be part of the >> implementation... > > Zeitgeist + tracker are complementary (and a nice team together). > > CouchDB is also a storage but with a different philosophy. The nicest part > is the synchronization... but maybe we could "wrap" tracker in a similar > code to allow the online replication. This is just a wild guess. I think its possible - here is a little something i've been hacking up on my train to work for couch pulling from tracker: http://github.com/Jc2k/tracker-replicator/tree/master And i've been talking to Rodrigo - couchdb-glib might make implementing a client of this even easier :) > Regards, > > Ivan John _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list