Dev: How webSpoon runs on RWT
RWT (RAP Widget Toolkit) is a web alternative to SWT and “largely” implements SWT APIs, meaning Spoon can become a web app with most of the source code intact. Note that RWT refers only to this widget toolkit, while RAP (Remote Application Platform) refers to the whole project, including its ports of JFace, Workbench, etc. The notable differences between SWT and RWT are
- Unimplemented SWT APIs (e.g., a part of GC, some Mouse events)
- RWT-specific APIs (e.g., multi-user environment, file up/download)
- Lifecycle of application and UI sessions
Because of these differences, the source code of Spoon have to be modified to run on RWT.
Architecture (image adapted from https://angelozerr.wordpress.com/2011/05/24/rap_step5/)
RWT does not cover all the SWT APIs because it's hard or impossible to implement in RWT. Thus, there are APIs that Spoon relies on but not implemented in RWT. If this is the case, one of the following countermeasures was taken.
- Modify (web)Spoon (e.g., canvas drawing using GC, Mouse event handling)
- Partially implement APIs (e.g., StyledText)
- Fully implement APIs (none so far)
There are some RWT-specific APIs that are required for web-specific purposes.
- Multi-user environment (e.g., session-unique singleton described below)
- File up/download
The lifecycle of a RAP application like webSpoon is quite different from the one of a RCP (Rich Client Platform: a set of frameworks such as SWT, JFace) application like Spoon. A RCP application is launched and terminated by a single user on a desktop, while a RAP application is started in the server-side and serves multiple clients. There is a notion of "UI sessions" in a RAP application, each of which is created when a client connects to the server. Thus, any object specific to the UI session should be separated from one another.
The singleton pattern is widely used in a RCP application. In a RAP application, singletons are shared between UI sessions, which would result in an undesired situation. In order to isolate singletons between UI sessions, these singletons should become session-unique. See here for more details.
When an object is desired to be shared between UI sessions for whatever reasons, this object should be created synchronously with the application launch.
For example, registerUIPluginObjectTypes and initLogging are executed in the main thread as illustrated below.
Lifecycle