Comments on: 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.



Maxim Olivier-Adlhoch
12-Apr-2007 15:46:29

will we be able to create scheme/ports out of plugins which do not follow the "Device" api?

With above description, It's not explicit if schemes intrinsincly ride on the back of devices.

12-Apr-2007 16:52:04
Cool, sounds like slowly reimplementing AmigaOS :-) Carl, where do timers and events belong in the scheme?
12-Apr-2007 16:54:45
I wonder if we will have capabilities to handle accessing File Allocation tables and more lower level hard drive stuff so we can design some other tools that some of us support pro's might benefit from.
Brian Hawley
13-Apr-2007 1:22:30
I wonder how layered pot schemes like http are implemented in this new model. Sounds great, though. I look forward to these new ports.
13-Apr-2007 4:49:42
Carl, will there be an access to ports or request layer, so that would be like event-block, so we can e.g. filter, regroup, prioritise requests etc.?

Well, that nearly sounds like R3 being close to OS kernel :-)

13-Apr-2007 13:01:08
The device concept in Amiga OS was one of my favorite and most used features. We routinely connected all kinds of oddball devices to Amiga OS, including breadboards with digital design projects, and we talked to people at NASA, Sandia Labs and ASU that chose the Amiga OS because of the ability to quickly implement interfaces to different devices.

A friend of my created a smart house with 192 different sensors, actuators, switches, variometers, relays, etc. that did everything from opening and closing the drapes, feeding the dog, tomatching the stereo music to the appliances in use (eg. the diswasher played "Purple Rain" and the toaster played "Color My World"....don't ask!).

The joy of Amiga-like devices joins the ease and elegance of REBOL. Ah...a breath of oxygenized digital air.

Sorry Pekr...there's quite a ways to go before it becomes and OS.

Dave Cope
15-Apr-2007 4:20:38
Would the described model be able to handle external interrupts from the device level? In particular, define a function which responds to a hardware event. (e.g. Change of state on an input pin or a burst of RS232 on a UART).

Maybe this is where the plugins provide huge benefits.


16-Apr-2007 13:07:19
Inferno Os is abstracting the devices too, is still actively developped on Google source and available in open and close source. And with such a name, it invites hobbyists and flamers alike :).
20-Apr-2007 8:23:13
What's about clipboard scheme ? Could we have in R3 a file & text copy (not only text copy) with clipboard scheme ? thx

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font span div a p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 15-Jun-2024 - Edit - Copyright REBOL Technologies -