RAP 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”.

RAP sync widget trees RAP protocol: all about messages

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.

You may also like...

Share this Post

Twitter0
Google+0
LinkedIn
Facebook

Tags

8 Responses to “RAP protocol: all about messages”

  1. Scott Lewis says:

    Hi Holger. As I mentioned in a comment to a previous posting, ECF’s transport independent structure is perfect for this problem. Further, you are still an ECF committer :).

  2. Thanks for the hint. I already answered you on the previous post. Here is what I have wrote:
    I think one problem of using ECF in this context is that the API’s you described are completely in Java. So, we always have to handle with client technologies like JavaScript, Objective-C and so on. I think a very lightweight protocol would be the best. The thing is, we need to couple the RAP server to some kind of message. The server has to understand this messages and synchronize the server side widgets. The other way around we need to make every client able to generate those messages and I don’t know if ECF is the right technology in this case. What do you think about the described situation?

  3. wanderer99 says:

    It’s an interesting idea but I can see some drawbacks. For one, maintaining the entire client widget state on the server means this won’t scale too well. Also synchronization of trees is, while conceptually simple, not algorithmically simple. See the various research being done on synchronizing filesystems and xml documents.

    Why not take the Universal Renderer approach? That is, create a browser that knows how to render RAP applications based on some description of it?

  4. Stefan Röck says:

    Hi Holger, cool stuff :-) Another task in your list could be a server-to-client update mechanism (UICallbacks).

  5. Csaba Koncz says:

    Hi Holger,

    I just can’t wait to see some details (will you use XML for the communication or something else?). I think the message type list is quite comprehensive (and UICallbacks would be indeed useful). My pet remote UI functions with only three widget messages (the first three from your list: creation, destruction and attributes synchronization).

  6. @Stefan: The UI-Callback is on the radar. Another problem could be the textsize determination, theming and layouting. But I think we figure out how to handle with it.

    @Csaba: I’m currently using json for the message. i will post about this later this week to provide you a sample message ;)

  7. Cole says:

    I like the idea of being able to execute native code on the client. You mentioned it in the context of migration, but I think it would be very powerful for other use-cases as well. For example, mouse track listeners could be implemented as a block of native code that gets sent to the client. Then every mouse move wouldn’t require a round-trip to the server, the native code could process the events and decide what to send and when. This is something we have been thinking about, but that is a little difficult with the current framework. Having support in the protocol format would be a great feature.

  8. @wanderer99: Thats what we wan’t to achieve with the protocol. Currently the server handles the whole widget state. With the protocol it should be possible to just send widget status information to the client and the client should know how to handle with it. Do you have any further information about the Universal renderer approach? Maybe some research papers? Thanks in advance.

8 responses so far

Written by . Published in Categories: Planet Eclipse

Published:
May 3rd, 2010
Follow:

Twitter Google+ GitHub Facebook