device filtering support

[Pete Batard]

On 2012.02.06 01:24, Michael Plante wrote:
> So I'll ask again the question I restored above:  what does this "filtering
> breaking libusb" have to do with the process vs thread discussion?
> Anything?

OK. I thought I had explained this before:
- Xiaofan and Travis see the alleged pollution from our current enum 
process unacceptable, even if done once per app (because launching a new 
app would still pollute => eliminated a threaded approach)
- Their proposed solution to remedy that is to change the general 
libusbx enum process on Windows to _always_ filter, as libusb-win32 and 
libusbK currently do
- My solution to avoid the above and meet their request of non pollution 
is a cross application process that would do the polluting enum once. 
Also has the advantage of querying the OS and USB common data we need 
once and could handle hotplug, which would probably benefit more than 
just Windows.

> It needn't be that drastic.  I'm saying that what worked at one point could
> continue to work if you went with the threaded approach because no one can
> pull the rug out from under you if you link statically.

But I don't see breakage if the process provides non libusbx specific 
session static data (well may be translated for libusbx specific usage, 
but I hope you understand what I mean there).

This data will be copied over into the same device structure we used, so 
the only thing it might break is apps that were poking around the enum 
list (and even then, we will still need some form of list to be kept 
internally).

> That fallback isn't
> available at all with the process.  You give us too much credit to say that
> someone necessarily has to poke at an internal structure to expose this kind
> of flaw, but say for a second that they do -- at least with the statically
> linked threaded version end-users can continue to use a version of the
> software after the company is long dead and gone.

Are you saying that the statically linked version would not be able to 
spawn a process (it would)? Or that we wouldn't be able to detect if 2 
incompatible processes need to be ran simultaneously if needed (we 
should, and there's nothing that should prevents us from doing just that)?

>>> but once we have devised our translation, it's not expected to
>>> change that much.
>
> The future is hard to predict.  It only takes getting it wrong once and the
> whole thing is shot.  See Vitali's compatibility matrix (if you can find the
> text; those messages are hard to read).  You add a row and column to that
> N^2 matrix for every time we get it wrong, and there are N*(N-1)/2 test
> cases, most of which will involve, by definition, truly ancient code.  Are
> you going to want to test against libusb-1.0.10 in 15 years (and yes, I'm
> assuming we release in a month or so)?

No, because 15 years from now, 1.0.10 will have been officially 
deprecated, just like Windows 2000 and MSVC6 already have from pretty 
much every piece of software out there, and if people want to obtain 
support for it, they better be prepared to. If a reuse of a 15 year old 
library is the main argument as to why the process idea is flawed, 
colour me unimpressed.

Are we serioulsy considering that libusbx versions have no expiration 
date? If that's the case, I think I'll leave the game, because if I 
cannot tell a libusb user 15 years from now "Your version is too old - 
you'll have to update your app and come back when you have done so", I 
might as well shoot myself.
5 years top is what I'd see as an expiration date for libusbx, because 
that's pretty much what everybody else seems to be doing. You want to do 
it longer, fine, but don't count on me there.

Regards,

/Pete