IO Devices in R3

Carl Sassenrath, CTO
REBOL Technologies
12-Apr-2007 18:13 GMT

Article #0084
Main page || Index || Prior Article [0083] || Next Article [0085] || 9 Comments || Send feedback

Here's a rough diagram of the IO (port) mechanism in R3:

Schemes [R]

Ports [R]

Requests [C]

Devices [C]

Where: [R] is implemented at REBOL level and [C] is implemented at C level.

Main Requirement

R3 needed to formalize the abstraction of what happens at the C layer for IO without extensive expansion of the API.


 SchemeAs they are in R2. They define a type of port, its specification and implementation. Examples, TCP, HTTP, SMTP, etc.
 PortAn instance of a scheme. A port is an externalized series. You open a port based on a scheme such as TCP.
 RequestA standard lower-level (C code) structure for conveying port actions to external devices. It relays commands from the higher level port to the lower level device. It is also used for replying from the device back to the port, and also for tracking the current pending asynchronous requests.
 DeviceA standard model of IO. Implements a set of commands via requests, and a method of replying to requests. Extremely lightweight and flexible. Support synchronous and asynchronous devices. Example device is basic TCP networking. (Those of you who were Amiga developers will understand the model quite well.)

Note that the request and device layers do not manifest in REBOL code. They are lower level.

Example devices:

A few example devices are:

 Systemspecial system IO such as interrupts, system shutdown, etc.
 StdIOlow level REBOL character streams for stdin, stdout, stderr. Very simple.
 Consolehigher level REBOL console functions like the R2 console window (with menus, etc.)
 Filelocal file and directory access (currently synchronous, but can be expanded to async).
 NetworkTCP/UDP networking interface. Asynchronous by default.
 EventOS and GUI event streams.
 Soundcontrol of sound channel playback

There will be others, such as databases, video, MPEG codecs, etc.


Standardizing on a device model greatly reduces the extent of the primary API (function library) between REBOL and the hosting OS. Why? Because 80% of the interface is related to IO, so providing a standard IO abstraction shifts all of that from the API to a dynamic, extensible mechanism: I/O devices.

An additional benefit: it will be possible to implement REBOL on hardware devices and embedded systems that have little or no OS. For example, an implementation can map "StdIO" to the serial port if so desired. Then, running REBOL, the prompt would appear on the serial device. You get the idea.


IO Devices implement a specific interface model. Although quite flexible, it is still a command driven request/response model. There will be external devices with functions that fall outside that model.

Fortunately, the great range of initial devices forces a design from the start that can handle a wider range of devices. There are standard commands such as CONNECT that have meaning for networking but not for filesystems, and also the IO request structure supports 64 bit external indexing and sizing. In addition, we can add new command types as the need develops.


REBOL plugins (not described here) can implement functions outside the range of this device architecture. So, features that don't fit well into a device model are still possible -- but as plugin libraries, not devices.

More Info

I'll be saying a lot more about this design soon. I will also be covering it extensively at the 2007 DevCon next month.


Updated 26-May-2017 - Edit - Copyright REBOL Technologies -