Acoustic Fingerprinting and QueryMaker (Bart and Max: read this)

[Bart Cerneels]

On Fri, Jul 10, 2009 at 12:18 PM, Soren Harward<stharward at gmail.com> wrote:
> Bart and Max raised issues with the way that the acoustic
> fingerprinting patch affects the QueryMaker, which needs to be figured
> out before I commit the patch.  I'm moving the discussion here because
> I find it easier to handle discussions on the mailing list than on
> Fisheye.  So if you don't care about the acoustic fingerprinting
> patch, feel free to ignore this thread.
>
> The acoustic fingerprinting system needs to provide two "use cases"
> for programmers:
>
> 1: Given two tracks, determine how similar one is to another.
> 2: Given a track, find other tracks in the collection that are similar to it.
>
> Use case #1 is currently handled in the Fingerprint class, called by
> way of FingerprintCapability, and implemented only in SqlMeta because
> local database collections are the only collections capable of storing
> fingerprints (as of right now; if Nepomuk collections ever become a
> reality, I'll add the functionality there).  Other than some
> sloppiness with the database schema which has been fixed, nobody seems
> to have an issue with how I have implemented this.
>
> Use case #2 is currently handled by QueryMaker.  More precisely,
> there's a "do nothing" function stub in QueryMaker, and only
> SqlQueryMaker overrides this stub to implement it.  Bart and Max,
> contrary to what both of you stated in your comments, adding a
> function stub to the QueryMaker base class neither adds a dependency
> on Fingerprint.h to the base class and all its children, nor does it
> require anyone who subclasses QueryMaker to implement the
> addSimilarityFilter function.
>
> I have designed the modifications to be as low-impact as I possibly
> could, and I don't know how they could have less impact without
> removing the functionality altogether.  It doesn't add a significant
> burden on anyone who wants to write a new QueryMaker for Amarok,
> because either the collection does not support fingerprinting, in
> which case you just ignore the function and let the base class do its
> job, or the collection does support fingerprinting, in which case
> you're going to have to write fingerprint-handling code anyway.
>
> Removing the filter from QueryMaker altogether would prove more
> complicated that it's worth because then any code that wanted to find
> similar tracks would then have to check whether the collection
> supports fingerprinting.  So you'd basically end up with a
> Capabilities interface for collections, which I think would be far
> more invasive than the QueryMaker change.
>
> The alternative would be to add something like a "tracksSimilarToMe"
> function to FingerprintCapability.  This makes less sense to me,
> though.  "Find tracks like this one" is a QUERY of the collection, so
> conceptually it belongs with the rest of the collection queries (ie,
> in QueryMaker).  This approach would also make the Fingerprint class
> vastly more complicated, plus slow down the queries significantly.
>
> --
> Soren Harward

I don't think you need a collection capability at all. At the moment
the fingerprint query is only available in SqlCollection. As long as
there is no 2nd implementation there are way better ways to do it. See
below.
Collection capability exist by the way, though they are a bit hacky.

I think we can come up with a solution that is a lot cleaner using
Bias/Constrained or "whatever is equivalent in your framework". I'll
use Bias in this example.