A few days ago I wrote about looking for metaphors to get to grips with what happens when a computer appears to be doing multiple things for multiple people at one time. The outcome was some ideas based on the physical metaphor of a house I lived in while studying at university. At that point I was still pondering possible meanings for the term “communication-oriented” which I had plucked out of thin air all those years ago. After a bit more thinking, I reckon I might have the beginnings of what this might turn out to be.

A lot of relatively early computer systems were built closely with their input/output (IO) peripherals. Printers, teletype keyboards, card and paper-tape readers were all common ways of getting information in and out of the core memory. In general these devices tended to work with one character at a time. Admittedly, some were “buffered” and would read or write a “line” of characters at one time, but the obvious basic model for input and output was as a stream of characters. This model was adopted by the developers of Unix, which has been by far the biggest influence on current operating system design. Pretty much every “smart” device you will encounter, from PC and Mac personal computers to the big servers in the datacenters and even the phone in your pocket have all been influenced by Unix, and one of the key things they all have is a “stream of characters” IO model. Sure, most of these systems also have alternative IO models (“block” devices for disk-like storage and a range of “special” IO devices for specific hardware) but the key programming model is a stream of characters. This model is used for screen displays, reading and writing to files, printing, communicating over networks with other computers, and loads of other uses.

This stream of characters model, while simple on the surface, results in a surprising amount of complexity. It can be hard (in some cases impossible) to tell whether a stream of characters has finished, so many implementations rely on “sentinel” characters (the usage of EOF (-1) in C input output libraries is a classic example, as is the use of byte 0 to indicate the end of a string. In other cases the process relies on some sort of character count at the start of a stream, or even on waiting for a time-out and guessing that the stream has finished. The sequential nature of the model also makes random access very tricky, and lots of code has been written over the years which works around this by keeping separate buffers of incoming characters or ad-hoc code to “push back” characters on to an incoming stream. Add to this that a large proportion of real communication protocols operate on “packets” of data. Pretty much all common network protocols use packet-based communication, as do a huge number of device interfaces. A stream of characters model is a very clumsy fit for these uses.

The upshot of this in my thinking is that perhaps a time has come for a different model to be at the core of a system. A model in which the primary unit of communication draws from the idea of packets, and uses it as the basis for all communication both inside and outside the system. Drawing inspiration once again from my student years, I have settled on the idea of a “crate”. A crate is a container which can hold up to a fixed number of items. Crates can be passed around, fully or partially filled and emptied, and stacked together for storage and transport. A crate seems a useful concept in this space.

When we add this to the Rooms, Doors and Lobbies notions from my other post we end up with an interesting approach to communication.

Anyone can grab a crate, and place it in a room. Once a crate is in a room, anyone in that room can add or remove items subject, of course, to the size of the crate. A crate can also be passed through a door and placed in a lobby, from which it may be grabbed and moved into a room. A lobby may have a limit on the number and size of crates which will fit. Sometimes it might make sense to pass an empty crate through a door so that it may be filled in another room and returned, sometimes one crate may be used both for passing stuff out of a room and collecting the response. A crate can even be taken through an exterior door and placed outside the house for transport to a different building.

All of this is metaphorical, of course, but as a programming model it does seem to fit pretty well with the realities of packet-based communication protocols, both synchronous and asynchronous.

I have been fiddling with some of these ideas, but it seems that this might be a clear enough formulation that I can start to code some examples.