Re: ITagProvider

["Kevin Kubasik" <kevin kubasik net>]

On 10/2/07, Joe Shaw <joe joeshaw org> wrote:
> 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.
>
Agreed, tracker could technically be the tagging backend/provider.
> (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.
>
I agree that they _shouldn't_ be treated differently, however, the
inherent complexity
> (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.
Agreed.
>
> > 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.
There were 2 issues I found with this model, they could be just a
matter of implementation.

1) We are still bound to a single backend system, intelligently
handling universal desktop tagging would be quite difficult.

2) Data replication, as well as sync/performance issues with users who
actually utilize tags (think thousands of tagged files).

Now time and energy could optimize these scenarios (I think). I'm
working on writing some other metadata backends so I get a better feel
for the system.
>
> > 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
>


-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog