Re: New module proposal: tracker

[Jamie McCracken <jamie mccrack googlemail com>]

On Tue, 2009-08-18 at 20:57 +0200, Lennart Poettering wrote:
> 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.

well that was my best attempt - sorry it would not be productive for me
to go and on about 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?
> 

Epiphany does not share its metadata with anyone else nor can you cross
query it

> > 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?

flickr/facebook 


> 
> > 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?

amalgamated view with local files. Eg get me all images could show both
local files and images on facebook/flickr

> 
> > 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?

AFAIK it does not extend into web services realm but eds could use
tracker as backend and get the web ones

> 
> > 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?

If it was fast and efficient why not? It would mean less code for them
to maintain and allow users to seamlessly switch music players and get
all the tags set elsewhere

> 
> > 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".

Well you would not have to write your own metadata server to get
equivalent functionality. Combined with tracker aware widgets you could
produce tracker powered apps much more quickly

> 
> > 8) Allow for different views of data such as get me all images instead
> > of traditional file/folder view
> 
> Isn't this Nautilus' job?

Nautilus remains wedded to file/folder

Think media centres here