Re: New module proposal: tracker

On Tue, 18.08.09 14:48, Jamie McCracken (jamie mccrack googlemail com) wrote:

> On Tue, 2009-08-18 at 20:26 +0200, Vincent Untz wrote:
> > Le mardi 18 août 2009, à 20:19 +0200, Philip Van Hoof a écrit :
> > > We'll do our best and are committed to formulate our answers in a
> > > non-vague way and improve the communication of the project's members,
> > > about the project, towards the community.
> > 
> > Maybe just clearly state what tracker (or tracker-store, the thread
> > already lost me :/) will bring to GNOME if integrated. I don't want to
> > hear about ontology, sparql, data store, indexer, or whatever. I want to
> > know what it will bring me as a user, and what opportunity it gives me as a
> > hacker, for my modules.
> > 
> > So, yeah. Just list use cases. (Somebody already gave a few examples in
> > a mail, iirc, but it got lost in the noise for me).
> tracker would provide a centralised storage of metadata which means
> multiple apps can share metadata safely, get notifications when it
> changes and know at design time what metadata is potentially available
> (via a schema similar to gconf)

Seriously. I cannot parse this.

> All metadata can be cross referenced in queries allowing for powerful
> search capabilities all via a uniform api and search language
> Use cases:
> 1) Centralised storage, tagging, search and query of bookmarks for
> Epiphany 

Uh? What's the point of 'centralizing' it? I mean Epiphany can do all
of this just fine anyway? You want to sell tracker to me listing
features that Epiphany can do anyway?

> 2) Zeitgeist integration of events with said search and query
> capabilities

Hmm, I cannot really parse this either.

> 3) Centralisation of all tags (nautilus, zeitgeist, fspot.
> facebook/flickr etc). No need to duplicate tagging in different apps 

Hmm, why should this be in tracker? not in gvfs?

> 4) Make web service integration easier with optional indexing of
> flickr/facebook

flickr/facebook are indexed anyway by, ... eehr ..., flickr and
facebook. What's tracker giving me here on top of that?

> 5) Allow for possibility of uniform services for things like contacts
> instead of them being redefined for all clients (evolution, pidgin, web
> services) - this would require a separate contacts service but a
> federated db like tracker is an essential component for this

Hmm? Isn't that what eds does?

> 6) Allow common database to be used for things like music players

Most people are using just one music player anyway... Do the media
player folks actually plan to rip out the databases and replace them
with tracker?

> 7) Allow more thin client development as minimal code would be needed to
> integrate search and metadata in apps if done from scratch without
> tracker

Could you be more explicit please? Sounds like you hope that "more
awesome software other people will write for us will appear one day".

> 8) Allow for different views of data such as get me all images instead
> of traditional file/folder view

Isn't this Nautilus' job?

Everything you listed above is available already in other
applications -- or I just don't get it. 

(I don't want to create the impression that I am opposed to the idea
of a desktop search engine. I actually do believe it makes sense, but
really, you need to do a better job selling the specific technology
tracker does.)


Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net           GnuPG 0x1A015CC4

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