Port Redesign Objectives

As I mentioned at the beginning of the REBOL 3.0 project, ports are redesigned. This is a primary goal of 3.0.

So, over the next few weeks, I'll be posting various notes about ports. Some of these are meant for your feedback and suggestions, and others are just for reference (to help prepare you for changes).

So, let me begin by stating the main objectives of the port redesign project:

1. The basic model remains the same
   In 3.0, REBOL Ports still implement the concept of external series. They are used to provide a robust and consistent access mechanism to files, directories, events, networks, databases, sound, encryption, etc. You can still open, close, read, write, insert, copy and perform other operations on ports.
2. Faster and more efficient
   In 3.0, we eliminate the waste. Under R2.0, all you have to do was probe system/standard/port to begin to wonder about wisdom of the design. As a simple example: why would a file port need stop-bits? Somewhere in the rush to get features out-the-door, the port model went out of control. As a result, every port took substantially more memory than it really required.
3. Simpler and easier to understand
   Writing new port schemes, or customizing existing ports required you to be a guru's guru, and even at that, a whole lot of guessing was needed. The flow of control could become so twisted that some layers of processing would redo or undo actions done by lower layers. In 3.0, we'll obey our REBOL motto: keep simple things simple.
4. Rethinking the index model
   There was a fallacy in the direct application of REBOL's series model to ports. The expected elegance of applying the index model was seriously flawed by the simple fact that many ports are not random access. Their index positions are modified as their state changes. (Consider what happens as you read from a TCP network socket.) This made the index concept go haywire and in some cases even forced excessive internal buffering where it wasn't necessary. In addition, we want indexing to work for port types that may be larger than the series index can hold (such as process a 5GB movie file).
5. Better error messages
   In 2.0 when a port threw an error (such as in the loss of a network connection) the resulting error message often gave no clue as to what port was involved. Developers were often left wondering... was the error from the event system or a network interface?
6. Port tracking
   During debugging or monitoring, there are times when you want to say: "get a me a list of all known ports". 2.0 did not keep track of ports. In 3.0 I plan to provide a mechanism that will. (Shades of Amiga Exec here.) In addition, this approach provides a simpler mechanism by which the garbage collector can invoke a close action on unreferenced ports before they get recycled.

Overall, I think 3.0 ports are an excellent redesign. I think you'll like it. In 3.0 will become so much easier to use and understand ports and to implement and customize your own unique requirements and variations.

So, keep a watch on this blog over the coming weeks....

3 Comments