device filtering support

[Michael Plante]

Pete Batard wrote:
>> - 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)

I'm going to have to side with Vitali here again:  show me the benchmarks,
and also consider how often such enumerations actually happen in practice.


>> 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).

Or if the format changes on our end.  Ever.  Period.


>> > 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)?


No, and based on your response, I think you've completely missed what I'm
saying.  Consider four alternatives:

1) statically linked (or private dll), thread approach
2a) system32 shared dll, thread approach
2b) statically linked (or private dll), process approach
2c) system32 shared dll, process approach

>From my perspective, 2a-2c all suffer from the same problem.  1 does not.
Namely, 1 can continue to live forever, with no maintenance.  You (Pete) can
forget that it ever existed, and you can deprecate it all you want, and as
long as it used to work, it will continue to, at least on that original OS.
Even if someone installs a new app with a new version of libusb.  You CANNOT
say that about any of 2a-2c.



>> >>> 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.

Maybe I didn't make the number 15 big enough to make my point?  Option 1
would still survive, no matter what the project does.  See above and below.



>> 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.

You sure can.  But the difference is a question of whose fault it is.  If we
go with 2b-2c, the breakage is probably OUR fault, no matter how many years
in the future.  If we go with 1, any breakage is probably NOT our fault.
Simple?

Regards,
Michael