[Bug 19803] "Fingerprint" is unclear

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19803

--- Comment #10 from Chris Wilson <cwilso@gmail.com> ---
(In reply to comment #8)
> Ports A and B have the same entropy pool. Port B gets a fingerprint that has
> something added to its entropy pool to indicate that it's natural
> fingerprint was taken. The application uses both A and B. The user
> disconnects port A, and its fingerprint gets freed, while port B still has
> the same fingerprint that was associated to it for the session. The user
> reconnects port A and here, magic happens, the algorithm tries if the
> natural fingerprint for the port is available, and it is because port B has
> a modified entropy pool, so the application can associate port A back to its
> rightful task, even though the port ordering has possibly been flipped. 

I don't see how you're going to maintain that port B - in the enumeration of
MIDI ports coming form the underlying hardware, not in the fingerprint stored
by the app in local storage - has a modified entropy pool.  Every time you
enumerate ports, you're going to start from zero with the fingerprint map - so
if A was removed, B will be the "natural fingerprint available" port.  Yes?

I think we can suggest matching based on the available info - port name,
manufacturer, version, even index of same - but if one of those ports is
missing (aka, to use your example, "there are not the same number of ports with
that natural fingerprint"), then all bets are off, and the match should likely
fail.  At the very least, that lets the DAW grab the exception and implement
their own hook.  I think that's captured in the current text, but not as
"MUST".

In short: I think we can say "deal with the case when the port name/etc. are
unique" - we can even say "deal with the case when the port name/etc. are not
unique, but the number of ports that match that doesn't change"; but if the
number of ports that match that "natural UUID" is different, it's going to have
to fail.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 7 December 2012 23:07:14 UTC