Re: ITagProvider

["Kevin Kubasik" <kevin kubasik net>]

On 10/2/07, Joe Shaw <joe joeshaw org> wrote:
> Hi,
>
> On 10/2/07, Kevin Kubasik <kevin kubasik net> wrote:
> > Agreed, tracker could technically be the tagging backend/provider.
>
> Sure.  I have pondered writing a Tracker backend for Beagle in the past.
>
> > > (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
>
> What's the inherent complexity?

Sorry, that sentence totally didn't finish, I meant to say the
inherent complexity of querying across multiple backends and merging
the results.
>
> > > 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.
>
> I'm not sure what the context of "backend" here is.  I think a desktop
> library would handle more than just files -- it'd be URI based like
> Beagle -- so it could handle emails, web pages, etc.
>
Agreed, thats not the issue, its on our side, intelligently merging
mutiple results from/for the same Uri.
> If you mean things like pulling from del.icio.us, then you'd just
> create a separate Beagle backend.  One for the local library and one
> for del.icio.us.  With all the focus GNOME is giving to the Online
> Desktop metaphor, there's no reason why the local database and a
> remote database like del.icio.us couldn't be sync'd independent of
> Beagle.
>
Yeah.. I guess the whole online paradigm works really well at making this 'ok'.
> > 2) Data replication, as well as sync/performance issues with users who
> > actually utilize tags (think thousands of tagged files).
>
> What's the concern specifically here?  The database will have to be
> timestamped somehow to make offline change notification reasonably
> performant.
>
Its that most tagging databases are databases, without said timestamp,
we end up throwing thousands of changes. In a perfect world every
change to a tagging database would have a timestamp, but I think that
in most cases we won't be nearly that lucky.

Take the frontrunner (leaftag) its a sqlite database without
timestamps, short of copying the db and comparing it every time its
modified, I don't see a sane way to notice and update just our
changes. In this type of case, it seems like we would be better off
just querying leaftag directly, and then processing its results
internally.

or I could be a fool, and this has all been solved already, I'm not really sure.

-Kevin
> Joe
>


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