github.com/ncar/agnoio (go): Package agnoio provides and interface and some implementers that allow easier use of low level IO in a way that is mostly agnostic to the actual IO transport. This was conceived of in order to abstract out many hardware dependant stream IO oriented hardware protocols in an agnostic manner.  This package attemps to answer the question of how to treat a network socket, serial port, I2C, SPI, and any other common streaming systems the same. All these transports have the following in common: they read & write bytes, can be closed, occasionally screw up and need to be re-opened (and that is what the IDoIO interface tries to provide).  Have you every wanted to do something bizzare as open a serial port, socket, zmq, UDP datastream, i2c or spi, or named pipe as agnostic as possible?  If so, then this package is for you.  This package attempts to be a thin vanier over several different io packages so callers can be mostly agnostic to what the underling mechanics are.  This package provides two different, but related, interfaces:  IDoIO (eye-do-eye-oh) and an Arbiter. An IDoIO is the basic read-write-open-close item that can read and write some bytes off of. Examples of an IDoIO include a serial port connected to a GPS NMEA (stream of location information) or some a free running sampling instrument (temperature, distance, speed, height, motor speed, etc) running over a tcp socket. An Arbiter is similiar in concept to an IDoIO, but it provides more of a command & control interface:  You send it commands, the remote side does something with the command, and provides a response. The Arbiter pattern might be found in sending commands to a servo to move to a different position, move the center frequency of a piece of test equiptment, or send some sort of power on/off sequence to a PDU in a data center.  IDoIOs usually need some sort of parser where Arbiters need to be instructed what to do.  Although you can write your own IDoIO (and I welcome patchs!), the this package provides IDoIOs for the following transports, which are selected via a URI dial string.  The schema (eg tcp:// or serial://) portion determines the backend for which IDoIO implementation is selected. Hereafter, the individual format for the remaing portion of the string is implementation specific, but should be transparent enough that someone with a crude undertanding would know what to make of the parameters.  The following schemas are provided by this package, and can be generically returned via the NewIDoIO() function:  This package makes use of the context package.  The passed context is used to derive child contexts and a cancel function.  If .Stop() is called, the cancel function will be called, and any further IO using the struture will end up in context errors.  This is helpful as it forces connection hangup and known exit behaviour.  All errors returned from this package either implicitly or explicitly conform to net.Error, which is to say after a cast, you have access to two additional func receviers: .Timeout() and .Temporary().  Timeout() returns true if the error was due to a timeout of some variety, and the transport is still opened. Temporary() returns true if the error is a temporary error, and true if the connection is closed and will need to be opened.  It is prefered that no structres provided by this package attempt to maintain a constant connection, but rather that when the connection dies / is killed / fails / returns errors, the caller should have a bit of knowledge as to what to do with these errors, such as reconnect, panic, stick a finger in a light socket, etc.  Generally each transport will have some sort of unique errors that might need special handling.
Keywords: ethernet|golang|golang-iot|nsf|serial