on May 3rd, 2010RAP protocol: all about messages
Last week I introduced you to the idea of a RAP protocol (bug 311355). This week I want to provide you with further information about how such a protocol can work. First of all we need to take a closer look on the current situation. RAP is divided into two parts. On the server side runs OSGi, RWT-Server and the application bundles. On the client side runs the RWT-client (JavaScript) to render the UI in a browser. The cool thing about this is that we can provide the SWT API on the server side to make single sourcing possible. For this reason we need to keep both sides, server and client, in a consistent state.
RAP already reached this consistent state with a fast and reliable solution. But the solution has one drawback. It couples the client and the server to each other. Currently the server sends JavaScript to the client. This JavaScript will be evaluated on the client side. With a protocol we need no JavaScript within a message. Therefore no evaluation is needed to bring the client in a consistent state. This makes the debugging of messages much easier. Another benefit of the protocol is that we don’t need to generate valid script code on the server side anymore.
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”.
But what should a message provide to keep two widget trees in a synchronous state? To answer this question I already analyzed the JavaScript responses from RAP. The result is that a message should be able to hold three different kinds of information:
- 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.
- Scripting: I think a protocol messages should be able to contain native code, e.g. JavaScript code. This will speed up a migration phase because hybrids are possible. With a hybrid I mean a RAP client which listens to protocol messages but also allows to evaluate JavaScript.
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.
