device filtering support

[Michael Plante]

Pete Batard wrote:
>> You do know that all our shared libraries have a version number suffixed
>> to them right? Why shouldn't we change that version number when our
>> process communication API changes?

Because there is no equivalent to doing that if you are only allowed to have
one process running at a time.  You said you would kill one and spawn
another.  The equivalent scenario is you DROP support for the following:

A) static linking
B) putting libusb.dll anywhere other than %WINDIR%\SYSTEM32
C) putting a version number on libusb.dll

In other words, when you agree that the only supported configuration will be
%WINDIR%\SYSTEM32\libusb.dll , and you will programmatically enforce that,
you will have done the equivalent and we can talk.  Sound absurd?  It is!


>> Or does breakage in a non public part of an API not follow the same
>> considerations as breakage in the public part?

It's kind of a moot point.  They're both avoidable, and things that happen
behind everyone's back at a time when quite possibly none of the original
developers are even involved anymore, of either the library or the
application.  That's the a terrible situation I'm trying to avoid.  That's
what I mean by "pull the rug out".


>> you can end up with 2 processes servicing 2 different versions
>> of the inter process API

Oh, now you say it.  Well, if you go that way, that DOES solve it.  I'm
surprised it took this long, though.  (Not to suggest I like it, but this
is, I think, a prerequisite in the design of a process-based solution.)

Regards,
Michael