I/O from binaries and an I/O behaviour

[Robert Virding]

Chris Pressey <cpressey@REDACTED> writes:
>On Mon, 5 Nov 2001 08:17:24 +0100 (MET)
>
>I'll go one step further, and ask: is there any reason both the io module
>and the bin_io module shouldn't both adhere to an 'io' behaviour?
>
>I realize that modules that implement behaviours are intended as callback
>modules, but I don't see why they couldn't be used just as well to
>establish an interface for calls of all kinds, not just callbacks.
>
>For example, a function in some other module could take an atom as an
>argument, which would be a module name like io or bin_io (or socket_io,
>serial_io, etc ad infinitum), and use that module for I/O by calling
>Module:open(Object, [read]) and so forth.  This would allow that function
>to seamlessly use whatever I/O its caller specifies.
>
>I think the real benefit here comes from the new behaviour_info/1
>function, so that conformity with an interface can be checked, even at
>compile time.  There are probably other places it could be beneficial, for
>example in the epop package, where a custom database driver can be
>specified; it could be required to live up to an epop_db behaviour, or
>some such.
>
>Any thoughts on this would be very welcome :)
>
>Chris

No, real reason.  I did look into to it many years ago, long before
behaviours in fact, and found that it wasn't trivial.  The problem is
that such a generic server would need to define a generic way of
getting bytes from and putting bytes to some device.  Some devices,
like files and binaries, work best with an synchronous call method
while others like terminals work best with a completely asynchronous
method.

Another complication is that for things like terminals you really need
to be able to interlace input and output requests in a sensible way,
like the terminal does now.

The best way I then found was to define a simple generic synchronous
io server which uses defined get and put handlers.  Other more
complicated devices like terminals would then need a separate process
to do their tricky bits.  This went against the current trend,
however, towards fewer processes as the BEAM is not really efficient
in sending lists (unified heap rules).

Actually the basic io protocol is pretty simple so I have not really
felt the need to be great.  I will look into it, however, when I get
the time.

Robert