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" <s...@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.
