Re: New module proposal: tracker



On Tue, 18.08.09 15:12, Jamie McCracken (jamie mccrack googlemail com) wrote:

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

That's a pity.

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

Share? With who? 

What does "cross query" mean?

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

Wouldn't a much simpler approach of doing that in the search tool
itself be the better idea here?

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

And why not simply teach eds getting the data from the web services
itself? Why stack things? We're not KDE.

And what do actually the eds people things of your great plans?

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

"Why not" is not a good reason.

If "seamlessly switching music players" is the only advantage you can
come up with then please try again. Seriously.

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

Hope is not a good argument here. Just hoping that you will
eventually have more apps using this is not a convincing reason.

With Hope you can win elections, not convince technical people. And
even if you could, Tracker is not quite Obama yet, is it? ;-)

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

So what does tracker give a media center that a simple "ls *.jpeg" (or
the gvfs equivalent) wouldn't give?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4


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