The DirectBuffer abstraction was created to solve the need to be able to 'cut in' to a rendering pipe horizontally, in order to be able to directly modify an intermediate vertically-organized (in-line) section. But there is also the need to modify a horizontally-organized (out-of-line) section, to establish a different type of fundamental abstraction. These will give GGI the ability (in American Football parlance) to "go long", not just "go wide", and thus I propose the DirectPipe.
A DirectPipe will represent a directly-mapped (and therefore mmap()able) command FIFO. This abstraction can be used to map hardware FIFOs such as a write-combined linear buffer or a DMA pipe, or software FIFOs such as a UNIX character device or SYSV shared memory segment. DirectPipes are typed with an abstract protocolic motif , not a pixel-buffer mapping motif like DirectBuffers. However, the two buffer types share a common characteristic: they are format-typed, not construct-typed, and they are directly mapped, not abstractly placed.
DirectPipes will be useful when it comes time to share access to a linear FIFO, much as DirectBuffers share access to the buffers they encapsulate. With a DirectPipe, we can 'massage' hardware or software FIFOs to:
* Interleave multiplexed command streams;
* Dynamically tune scheduling of buffer flushes and syncs;
* Optimally convert between FIFO types and styles;
* Serialize and deserialize command streams between client-server hosts over various protocols and addressing methodologies.
Finally it is important to note that both DirectBuffers and DirectPipes should probably be further moved into LibGG, they are so basic and fundamental to abstracting flow and control. This way, other libraries besides LibGGI (such as LibGII, which could use DirectPipes to manage event queues in hardware and software) could take advantage of the DirectNN style buffering abstractions to enhance performance.