device filtering support

[Pete Batard]

On 2012.02.05 22:39, Michael Plante wrote:
> Pete Batard wrote:
>>> My preferred idea was pretty much to go with creating a thread on init,
>>> but you guys still didn't seem to see it as acceptable
>
> Who is "you guys"?  I thought I said from the beginning that I thought that
> was a reasonable compromise.

That was Xiaofan and Travis. Should have been more explicit there.

>>> But it's even worse! You've broken libusb, and users can no longer rely
>>> on expecting the same features across platforms. And suddenly, your
>>> _generic_ library becomes both lot less generic.
>
> We've lost the context here.  Please elaborate.  Doing *what* has broken
> libusb?  It sounds like you're describing an effect, no topology, as the
> breakage, but you haven't described the cause very clearly.

Cause is filtering on driver class GUID. For instance, you'd get an enum 
that will only feed properties of devices that are handled by the K 
driver. Hubs, proprietary would either not be listed or miss some data 
that our users may expect libusbx to provide.

My understanding of what the libusb-win32 and libusbK current enum 
process does (I might be wrong) is that it only lists a bunch of devices 
that meets a set of GUIDs that are known beforehand.

>>>>> They may even come to RELY on certain bugs to
>>>>> continue to exist.
>>>
>>> Really? Are we becoming Microsoft there? ;)
>
> Not us, but our developer-users may behave that way.  The fact is that the
> moment we impose this approach, we have to support every possible type of
> developer-user out there, including Microsoft-like developer-users (just to
> quote you, not that it matters what it means -- every means every) and
> developer-users that may go out of business and/or stop updating their
> software.

Then you're misconstruing what I say (or if I said it otherwise, I need 
to amend it). I want to support as many users as possible as long as 
their expectations are reasonable.

CJK users expecting to be able to compile libusb from git?
Sure that's a reasonable expectation. If we have to patch their libtool, 
because their version is likely to be faulty (especially if no release 
of libtool currently includes the required patch), then we should.

Windows git users expecting MSVC project files to have CRLF endings?
Reasonable too. If we're not aware of any git bug (which we weren't at 
the time) and adding CRLF to our repo is the only option we seem to 
have, we should go for it.

Users relying on libusbx bugs or poking inside our internal structure to 
access data outside of our APIs (I know some of those users)?
No way!
Microsoft does it because it gets pressured from large accounts to keep 
their software working when it shouldn't. But once you remove money from 
the equation, as in our case, then you can't have that kind of pressure.

> This is in contrast to the fallback mechanisms we had before with static
> linking, where one program could use a very old version and one program
> could use the latest and greatest, both at the same time.

Except, and I think this is the part I didn't make clear enough 
previoulsy, the process aims at mirroring OS and USB data to provide it 
to libusbx apps. and not any of the libusbx-specific internal data we 
currently use. It may not be exactly the same format as what the OS 
provides (eg. Windows uses a set of enum for device speed, we may use 
another), but once we have devised our translation, it's not expected to 
change that much.

> I remain
> unconvinced that a public API can support both for all time.  There will
> eventually be breakage, even if it doesn't happen until 2.0 or 3.0.  And,
> for this approach, breakage is never acceptable, even across major versions.

There will be breakage if the OS or the USB specs change. There may be 
addons if we find out we want extra (for instance, we used to ignore 
device speed until recently, which, if we had a process implementation, 
we'd have to add to the communication API), but I wouldn't call these 
breakage. Check the API used by the app, and return the relevant data.

Regards,

/Pete