Re: New module proposal: tracker
- From: Lennart Poettering <mztabzr 0pointer de>
- To: desktop-devel-list gnome org
- Subject: Re: New module proposal: tracker
- Date: Tue, 18 Aug 2009 20:57:33 +0200
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
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
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 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
> 7) Allow more thin client development as minimal code would be needed to
> integrate search and metadata in apps if done from scratch without
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
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
] [Thread Prev