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.)