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.
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.
-pekr- 12-Apr-2007 16:52:04
Cool, sounds like slowly reimplementing AmigaOS :-) Carl, where do timers and events belong in the scheme?
Paul 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.
-pekr- 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 :-)
Scot 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.
Best.
Norm 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 :).
Philippe 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
