Re: ITagProvider

["Joe Shaw" <joe joeshaw org>]

Hi,

Sorry for the delay.

On 9/28/07, Kevin Kubasik <kevin kubasik net> wrote:
> Downside is there have been attempts at a universal
> tagging library, what i would really love (in an ideal world) is if we
> crafted events through the indexservice, meaning that while we could
> offer a way to work against the tags from the BeagleClient API, you
> wouldn't have to implement it. However, for tag querying/listing, we
> would probably require a native API.

Is the idea here to write the integration in Nautilus which would call
the Beagle APIs to add and set tags?

If so, I don't think this is a good solution for a couple of reasons:

(1) It's Beagle specific, and with Tracker out there and a fairly
divided community, a single implementation will never get all the
buy-in it needs at this point.

(2) Tagging really has nothing to do with desktop search and indexing.
 Tags should be indexed by the indexer and made available through
search, but fundamentally they're no more related than metadata in
MP3s, JPEGs, emails, etc.

(3) The amount of code you'd actually have to write to do this as a
totally separate library in C isn't that much more work.  You'll be
able to integrate with D-Bus, have the potential to get community
buy-in for the library, and we can still use it in Beagle.

> The specifics of how much of this were going to make beagle
> responsible for (is beagle almost like a 'tagging adapter'? do we want
> to provide complete bi-directional support? or do we encourage people
> to work through the provider that we are using as a backend?)

These problems all go away by implementing it as a separate,
standalone library.  Beagle's UI simply uses the library widgets,
talks to the library APIs, and gets notification (and reindexes
updated tags) via D-Bus.  The only extra benefit something like Beagle
gives you is the ability to push file system events back into the tag
library, and Beagle needn't do that -- any file system monitoring
system could provide that.

> I would just prefer that instead of Beagle trying to
> provide a robust tagging api, we just integrate it into our search
> intelligently, and treat it as a property.

I agree wholeheartedly with this, and it's the reason why I wrote the
Nautilus metadata backend in the trunk.  A tagging library backend
could fit pretty cleanly into this mold.

> Well, the problem here is, I really don't want us to be tied to one
> index, or one backend. I would think (and I could be wrong here) that
> once we have merged the results from a backend, we could add any Uri's
> that were tagged with one of the query words. The key point here is to
> have a universal tagging store that transcends our backend system.

Take a look at the Nautilus metadata backend.  This is basically what
it does.  It doesn't have an indexing backing it, it simply sets
additional properties on documents in existing backends.

> > Or, if you're feeling particularly adventurous, rewrite the FSQ.
> > That's the biggest consumer of memory at this point and has problems
> > like being unable to search by parent directories.  I've described the
> > issues with it in more detail in a previous email, I believe. :)
>
> I seem to remember something about that. Its probably overkill right
> now, with the slew of new features, but I am curious about it from a
> design standpoint.

Maybe, but I consider it the #1 problem with Beagle right now.  I
couldn't find my previous email about it, so I'll type it up soon.

Joe