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

Problem with thinking of these tecnologies as what wil lit give the user is a wrong approach IMHO. The 3 technologies provide developers of applications standards and tools to provide better user experience. Unless the technology has a client (Such as the Tracker Search uses the Tracker Storage) there is no point of discussion.

Applications that use or depend on these technologies should suggest these modules to be integrated. Not the Developers themselves since all 3 projects don't provide first hand experience, but rather indirectly over other apps.

If GNOME Shell (which will uses Zeitgeist thanks to GSoC) and Zeitgeist will start sotring its events into Tracker-Storage then by all means Tracker-Storage will be included.

2009/8/19 Philip Van Hoof <spam pvanhoof be>
On Wed, 2009-08-19 at 00:27 +0200, Rodrigo Moya wrote:
> On Tue, 2009-08-18 at 16:48 -0400, Matthias Clasen 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 ?
> >
> > 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 ?
> >
> > After that, it might be possible to evaluate whether tracker,
> > zeitgeist, couchdb or something else can be part of the
> > implementation...
> >
> couchdb provides just the storage of any kind of data, no indexing,
> searching, etc, so I think they solve different problems.


> In fact, tracker could just use local files as storage or a couchdb database.
> If using couchdb, it would get replication and synchronization for free,
> but it would still provide the indexing

We were recently discussing using CouchDB as a possible backup endpoint
for Tracker, and/or as a redundant storage location for user-unique
metadata. The stores to CouchDB would in latter case be synchronous (not
as a result of a backup command, but immediate).

With user-unique metadata I mean the non-reproducable / not-cache data:
the data that is set by the user and therefor uniquely stored. For
example the tags on resources that have no physical representation on
your filesystem. (Contacts and tags, for example, don't necessarily have
a physical representation on your FS).

We evaluated CouchDB as a primary store over sqlite, but CouchDB lacked
*very* important features. This makes it undoable. Feel free to get in
touch with us to discuss which precise features I mean.

Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org

desktop-devel-list mailing list
desktop-devel-list gnome org

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