Comments on: 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

Comments:

Brian Hawley 23-Mar-2007 14:25:52	This all sounds great so far. I am particularly interested in the index model changes and how it would affect buffering and random access, where applicable. Whatever the port model turns out to be, as long as I can use PARSE or something like it on a port I'll be happy. I want to be able to parse data incrementally, data that isn't necessarily all there yet and might not be able to fit in memory. Incremental parsing with the PARSE dialect might require some kind of buffering to handle the backtracking, either in PARSE or the port internals (or both). It may also require the engine to wait on the port if the data isn't all there yet. This is starting to sound complicated. Perhaps it would be better for me to implement a different parsing method, one that is intended to be incremental. A pull-style event-based parser could be implemented as a port, and even pull data from another port as needed. That would mean that port waiting would need to be reentrant. How would this work with multitasking? Every method of incremental parsing could be shaped by the design of the port model. Who else has a task like this that can generate some new questions?
Anton Rolls 25-Mar-2007 1:34:10	Agree - all looks good.
Volker 3-Apr-2007 5:40:50	I am happy if i can port my stuff to this modell :) Parse on ports would be great. And a combination of string/block, where datatypes can be used and are automatically loaded. And a parse with a retry. idea: when parse fails, add more data, parse again. without redoing the successfully parsed part. But maybe that is for r4? Or can be done with tasks?

Post a Comment:

You can post a comment here. Keep it on-topic.