To realize the protocol a well formed message will be needed. To create such a message we need to abstract the described situation. The described RAP scenario is nothing else than synchronizing widget trees. Take a look at the picture above to understand what I mean with “synchronizing widget trees”.
- Meta: Every message needs meta information which describe the current request/response. For RAP this message part can hold information about the current request count or the settingstore.
- Device: As you probably know, RAP is multi user aware. Therefor every user gets a new instance of Display. The display marks the root node of every widget tree. So, the display is always the same while a user session exists. As a result of this, display information are needed on every request/response. With display information I mean information e.g. about the focused control or mouse coordinates.
- Widgets: With widgets I mean information that are widget relevant.
I think the most interesting of these three message parts is the widgets part. The whole synchronization process should be modeled by this part. To do this, the widgets part must be able to represent seven different tasks:
- Construction: When a widget is created on the server side it should be created on the client too.
- Destruction: When a widget is going to be disposed on the server it should be disposed on the client too.
- Synchronization: Ever user action has a status change as a result. This changed status need to be sent to the server. On the other side, server widget status changes should also be sent to the client.
- Eventlistener: With RAP we live in a distributed environment. As a result of this every event on a widget provokes a request to the server. Currently only events of interest will be sent to the server to keep the count of requests as minimal as possible. To perceive this the server needs to inform the client widget if it should send requests for some kind of event.
- Events: When an event needs to be send to the server, the event order matters. E.g. if an widget has two listeners for mouse and selection events it’s important to send the correct event order to execute the correct server code. In the example the right order is: mouse-down, selection and finally mouse-up.
- Methods: Sometimes it’s necessary that the server executes a method on a client widget. Widgets are just objects on the client side.
I would like to know what do you think about the described message content. I think the described content should cover a whole synchronization scenario. Maybe you have some ideas about speed up things or make them more clearer? I think the next step on the way to the protocol is to model an example message and to choose the messaging format. I will keep you up to date about the progress.