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

[Ian Monroe]

On Fri, Jul 10, 2009 at 8:34 AM, Maximilian
Kossick<maximilian.kossick at googlemail.com> wrote:
> see comments below
>
> On Fri, Jul 10, 2009 at 2: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.
>
> Yes, I have no issues with FingerprintCapability.
>
>> 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.
>
> Which is not what I said. To quote myself: "Adding this method to
> QueryMaker adds a dependency on Fingerprint.h to the querymaker in any
> collection that wants to support it ... which is a sure sign that this
> is wrong from an architectural point of view."

Another way to do it is by considering this a SQL-only feature (which
it is) and just implementing it in SqlQueryMaker and not QueryMaker at
all.

Ian