Re: Tracker, Zeitgeist, Couchdb...where is the problem ?

[John Carr <john carr unrouted co uk>]

On Wed, Aug 19, 2009 at 2:53 PM, Ivan Frade<ivan frade gmail com> wrote:
> Hi,
>
> On Wed, Aug 19, 2009 at 2:11 AM, Thomas H.P. Andersen <phomes gmail com>
> wrote:
>>
>> On Tue, Aug 18, 2009 at 22:48, Matthias Clasen<matthias clasen 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