In order to reduce the size of the library interface between the REBOL kernel and its environment, R3 introduces the concept of a device. This is especially important for lower level REBOL ports (e.g. TCP networking).
The diagram below shows the basic relationship between schemes, ports, requests, and devices:
specifies a type of port, such as file, TCP, event, sound, etc. The scheme creates a port, which is:
a specific instance of a scheme. For example, when you read a file, the scheme is used to create a port that accesses the file and its data. Each open file has its own port.
is a lower level (C) structure used to communicate between a port and a device. In the case of a file, it passes fields like the file name, date, size, and data to be transferred.
is native C code that implements a standard set of access methods for a port. Example methods include open, close, read, write, create, and delete. This level is where file or network I/O actually happens.
Only ports that require native support need requests and ports. Higher level ports, such as HTTP, do not directly create requests. Typically, they use lower level ports, such a TCP, and those do use requests.
The primary benefit of this design is that it formalizes a method for accessing a wide range of devices without expanding the REBOL-to-environment API for each device. (In a way, it implements a mini operating system to keep REBOL as system-independent as possible.)
Also note that requests and devices do not appear within REBOL code itself. They are purposely kept isolated in order to eliminate potential interdependencies in future versions of REBOL (or improvements to the device code itself.)
This definitely sounds interesting. I look forward to the posting of your examples for those of us who can't make to DevCon.
Scot 26-Apr-2007 11:23:46
Brilliant! Some similarities to REBOL/Services which is outstanding. Very consistent implementation. Amazing really! My mind is literally overloaded with possibilities!
-pekr- 27-Apr-2007 9:18:01
Scot,could you please elaborate on what possibilities you have in mind? :-)
Scot 27-Apr-2007 11:03:12
The REBOL virtual machine will no longer be tied to a specific hardware. Like REBOL/Services the device developer will need to include only the commands it needs to operate, allowing scalability from the simplest DSP chip to the most complex CPU.
So there is a possibility that REBOL could be used for just about anything with no RT involvement.
If you take REBOL/Services and combine it with devices, you have an incredibly secure system that can literally do anything there is hardware to do.
Imagine any hardware device being able to communicate/control/cooperate/share with any other hardware device or software application with a line or two of code. That is what this creates.