On Jun 9, 2012, at 12:58 PM, Stephen R. van den Berg wrote:
I briefly checked, and as far as I can see, libusb-1.0 is the *only* usb library/interface being offered which is cross-OS. This does not mean that in the future, something else might arise which offers the same, but I'd consider it extremely unlikely. So, we could name it libUSB or similar, but for brevity, USB sounded better.
I wasn't necessarily suggesting I had a better idea, or even really disagree with using USB, and agree that libUSB is kind of an ugly name, but calling it USB suggests that it may be canonical, when there are a number of (pretty important) holes in its functionality that someone else might need to fill with an overlapping bit of code: HID devices, as an obvious example, and something I've been dabbling with in my spare time.
AFAICS, libusb is actively being ported and/or offered on several OSes. But if you know of competing offerings and/or know that libusb has shortcomings which make it likely that some would not want to use it, please speak up.
Well, I was thinking in terms of someone creating a native module for certain functionality, they'd then be forced to pick a different name (example: the various JSON, JSON2, JSON3 modules floating around).
What would be nice if there were a way to have providers that can be registered and then used (much like the Sql.Provider namespace). If the USB module consisted solely of classes and didn't have any module.pmod magic, one could use join-nodes to blend them together, but then they'd need to be in different module roots.
I'm definitely not arguing in favor of a Java-style namespace, but rather advocating that modules going into the non-Public root be designed with consideration to the possibility that there might be overlapping functionality down the road. It's certainly possible that nothing comes out of it, but at least it was thought about.