Pete Batard wrote: >> If we go this route it means that every time Peter wants us to implement >> an half-assed solution that we shouldn't follow in the first place,
Peter's recently been very accommodating about copying patches that he probably doesn't want in libusb, and quickly. I don't know if you've noticed that. >> he >> just has to arrange a way to make an app crash when switching to >> libusbx, It's a fair concern in the hypothetical, but who is trying to follow whom right now, and who should we really be concerned about trying to break whose code right now? I submit that, based on that long branding discussion, you might actually be projecting your own behavior onto Peter. Peter has been guilty of acting slowly, while you have been trying to make things difficult purely for the sake of being difficult on anyone who doesn't yet want to commit. Each has its disadvantages. The latter is far more characteristic of the cynical situation you outline, however. >> To me, trying to delay this inevitability doesn't seem very productive. Maybe. >> In its current implementation, as I explained, I very much see Peter's >> versioning buggy as it unnecessarily breaks cross-platform, Did you file a bug? If you just means it doesn't always produce an output, you could say the same about the fact that I don't get function names in usbi_dbg. Should we get rid of function names for everybody? >> Any application that uses Peter's versioning will have >> issues when it comes to Microsoft compilers Have you tested this? >> 2. Ergo, if it crashes, it is trying to do something with regards to a >> versioning element that we do not carry out in libusbx and that needs to >> be modified >> 3. Ergo, not having the field is likely to actually improve the >> application if it forces the developer to update it, whereas keeping it >> may very well silently break down the app down the line, in a more >> damaging manner. For instance, the application may have used the extra >> field to apply a workaround for a bug in a specific libusb version and >> when ported to libusbx, this workaround will not be applied for the >> equivalent libusbx version with the same bug => end users will pay the >> price. Yes, I agree with you here. So a function that returns a boolean indicating which branch of the fork you're on would be a great API addition if and only if we can get Peter to agree to it (i.e., such a new API must be compatible across the fork to make sense). >> My vote however would be to place a big "OBSOLETE - IF YOU USE THIS >> FIELD, UPDATE YOUR APP FOR LIBUSBX VERSIONING" How about "may be deprecated, depending on WHETHER we figure out how to get it working with msvc"? I am not convinced we won't. I think Peter showed awhile back how to do some tricks with cmd.exe that we still haven't run to ground. And there are pre/post-build steps. It would be ugly, no doubt. And we could document it to be always-blank, in the meantime, as Hans has said recently elsewhere. Regards, Michael ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
