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.
Definitions
Scheme
As they are in R2. They define a type of port, its specification and implementation. Examples, TCP, HTTP, SMTP, etc.
Port
An instance of a scheme. A port is an externalized series. You open a port based on a scheme such as TCP.
Request
A 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.
Device
A 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:
System
special system IO such as interrupts, system shutdown, etc.
StdIO
low level REBOL character streams for stdin, stdout, stderr. Very simple.
Console
higher level REBOL console functions like the R2 console window (with menus, etc.)
File
local file and directory access (currently synchronous, but can be expanded to async).
Network
TCP/UDP networking interface. Asynchronous by default.
Event
OS and GUI event streams.
Sound
control of sound channel playback
There will be others, such as databases, video, MPEG codecs, etc.
Benefits
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.
Disadvantages
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.
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.
