"H. William Welliver III" bill@welliver.org wrote:
/.../ As has been pointed out, it's possible to have the c-level code be in a place holder module (like _USB) and then inherited into the right place via a pike module.pmod,
That would perhaps be a good thing to do.
but it still means that any supplementary modules would end up in a module.pmod + dirnode, which sometimes (frequently?) results in odd behavior.
What kind of odd behavior is that? I'm not aware of any specific problems of late with the dirnode stuff. Well, with the exception that inheriting them won't do what you want, but I don't think that's a serious problem since inheriting modules is quite uncommon.
That's the origin of my suggestion that a library glue module not take up the root of a potentially diverse module tree.
If libusb is as generic as srb says (I haven't looked at it myself), then I think it'd be ok to grab the name "USB" for it. It doesn't seem to get too messy if people start to extend it with more advanced functionality, and it's fairly unlikely that a contender will actually materialize in the foreseeable future. Unless perhaps you have concrete plans to develop some more abstract usb interface?
My opinion here is also based on my general scepticism towards container modules - reserving USB.pmod as a container for all things usb-related isn't something I particularly fancy. So that only leaves the possibility of a "properly abstract" module that would fit better, and whether it cannot be joined with srb's low-level stuff in a decent way.