As a second datapoint, I've created a few modules (not all public, though), that I've placed in Public.IO, and my thinking pretty closely aligns with what Stephen has indicated: modules for operating with non-software I/O devices. Another datapoint from outside Pike: Apple's IOKit is all about device drivers, so I think it's not an uncommon line of thought that I/O typically involves a software-hardware interface in some way.
Though, also keep in mind that not everyone is going to be able to use libusb, so while I don't advocate over-classifying things, it might be somewhat ill-considered to use a generic (USB) name for something that's actually quite implementation specific, unless you were also planning on offering a generic interface to multiple USB-IO backends. Consider this case-in-point: file event notification apis are generally OS-specific, so we have System.Inotify and (soon) System.FSEvents which will hopefully plug into a more universal interface that works no matter what OS you're running.
Bill
On Jun 9, 2012, at 11:16 AM, Stephen R. van den Berg wrote:
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
Martin Stjernholm wrote:
"Stephen R. van den Berg" srb@cuci.nl wrote:
Then I thought about what these things are about, and decided that the (in my mind) logical group I'm thinking about all has to do with *hardware* I/O.
Hmm... Maybe the top-level module should be named HW or Hardware then?
Well, that is too broad a term, I think. It does prove a point though: that it is apparently not obvious what hierarchy to put modules/classes in.
So I'm currently implementing USB and OneWire, but I could imagine that other stuff that belongs in this category would be things like: I2C, SPI, 1-Wire, USB, JTAG, MIDI, PC keyboard, UART
(Personally I favor a very flat namespace - the top level is afterall the most convenient one, so let's use it. ;) I've never understood the benefit of Standards.pmod, in particular.)
Well, I can understand both camps. Anyone else got opinions?
Well, I'd prefer not having them at the top-level since they're mostly somewhat unlikely to be used by a random Pike program, and it makes sense to group them together.