Re: Proposed module: tracker

[Joe Shaw <joeshaw novell com>]

Hi,

On Wed, 2007-01-10 at 16:26 +0000, Jamie McCracken wrote:
> Joe Shaw wrote:
>> [snipped my concerns about Tracker]
>
> all these also apply to EDS too yet no one complains?

Some of them apply.  EDS isn't a general data store; it has APIs and
backends that are very specific to the types of data it stores.  Also,
very few applications (none other than Evolution, I believe) actually
store info in EDS.  They're all read only, consuming EDS's data.

> Tracker is object to object with key values as properties so it can do 
> more complex stuff (like a playlist object is a collection of music 
> files). 

Sorry, I don't understand what you mean by "object to object with key
values as properties."

For your playlist example, I have a hard time believing that Tracker can
offer a more optimized storage strategy than one that is tailored for
the application.

> If we ever want first class objects or semantic web style functionality 
> then stores like tracker/EDS are needed.

I agree that things like EDS are needed.  For a music player, it should
absolutely expose its data to the desktop; I said exactly that in my
last email.

> They are not slower - in many cases they result in far fewer disk seeks. 
> The key is to get stuff in bulk (like get all the properties in one call 
>   as opposed to getting each individual ones separately). This 
> eliminates the IPC overhead (something GConf needs too)

You either have IPC round-trip overhead, or you have memory overhead in
sending these large messages.  If you're sending them through the D-Bus
bus, message passing overhead is very high, because it validates every
message.

It's not uncommon for music libraries to have in excess of 10,000 songs.
Since this is often thrown around as a potential use case, I think it's
basically a requirement to see this implemented (even prototyped) using
Tracker before its suitability can be determined.

> And one API is easier to learn than a multitude for different metadata 
> and keyword systems (honestly how many systems do we need to do tagging 
> and metadata?).

Again, no one has articulated what the "metadata problem" is.  Tagging
is a pretty easy one to solve, and we can solve it with one API.
Leaftag could be that API, or something else could be that API.  It
doesn't really matter.

> Some examples of how tracker can improve the desktop :

These are fine ideas, but let's see them prototyped first, so we can
make an informed decision about whether it's practical and works, rather
than accepting it prima facie.

Joe