Rebol-3 and ports
26-Dec-2009/13:48 Filed in:Rebol 3
The Rebol-3 port model was completely redone. The goal is to simplify the model and reduce complexity. As I’m not a Rebol-2 port guru nor had to touch this stuff intensively I thought: This needs to change when using Rebol-3!
The Rebol-3 port model was completely redone. The goal is to simplify the model and reduce complexity. As I’m not a Rebol-2 port guru nor had to touch this stuff intensively I thought: This needs to change when using Rebol-3!
And, I need to get into this network port stuff anyway, while working on my new xpeers-II communication layer.
The information about ports in the Rebol-3 documentation, Wiki etc. is pretty good (even it’s a bit scattered over several pages). But there is one thing missing: A sequence diagram how everything works together. So, I started to create a sequence diagram that tries to show how everything fits together between a client & server.
Here is the current version of the diagram (scaled to 70%):
Overall I think the sequence diagram is correct. I’m not totally sure about the role of the Actors. As I understand it, the Actor is the function interface for ports. It could be that actions like READ / WRITE from the AWAKE handler first go to the Actor and than down to the TCP Device.
What I learned while building this diagram is that it’s crucial to trigger the “next round” of events from the AWAKE handler. For example: Inside the WROTE handler a new READ is done, this will wait for some data to arrive and than generate a READ-EVENT etc.
I have renamed the AWAKE events to include the post-fix -EVENT, to make clear there is a difference between the READ action and the READ-EVENT.
And, I need to get into this network port stuff anyway, while working on my new xpeers-II communication layer.
The information about ports in the Rebol-3 documentation, Wiki etc. is pretty good (even it’s a bit scattered over several pages). But there is one thing missing: A sequence diagram how everything works together. So, I started to create a sequence diagram that tries to show how everything fits together between a client & server.
Here is the current version of the diagram (scaled to 70%):
Overall I think the sequence diagram is correct. I’m not totally sure about the role of the Actors. As I understand it, the Actor is the function interface for ports. It could be that actions like READ / WRITE from the AWAKE handler first go to the Actor and than down to the TCP Device.
What I learned while building this diagram is that it’s crucial to trigger the “next round” of events from the AWAKE handler. For example: Inside the WROTE handler a new READ is done, this will wait for some data to arrive and than generate a READ-EVENT etc.
I have renamed the AWAKE events to include the post-fix -EVENT, to make clear there is a difference between the READ action and the READ-EVENT.
0 Comments