Thanks …

There is no disagreement from our side that 1:1 replicas of RCP apps in the web are often not a great idea. But nobody forces you to go down that path. When we started the RAP project single-sourcing was not our major concern. But our users pushed us very hard into that direction, and we think it is a good idea to listen to your adopters. Now, even with many things still missing, we enable you to re-use a large parts of your code for both desktop and web.

In a commercial project we experienced ourselves that being able to have a single code base is extremely valuable, but we needed to diversify the UI between web and desktop. We ended up with the following plugin architecture:

foo.bar.core
foo.bar.ui.base
foo.bar.ui.rcp
foo.bar.ui.rap

In our project we are able to share about 80% of the code, after we made the core multi-user aware. Before using RAP (and OSGi on the server side) we had a reuse factor of 10%. Your mileage may vary in your project.

With respect to technology decisions I am taking a different perspective. By no means I disagree that you should choose the technology that suits your requirements and not the other way around. I think that is a pretty common knowledge, even if it is not always practiced. My perspective is about platforms: Enterprises are choosing (one or multiple) platforms with respect to their consolidated requirements, and in a second step they are mapping those requirements to the available platforms. Having server-side Equinox, and RAP, and Riena, and EclipseLink, and Swordfish, and eRCP is just expanding the capabilities of the platform by a large degree - thus making it a better platform for enterprises.

A last word about “the characteristics of technical systems”. Those are changing over time, and even if misused with respect to the original use cases the web technologies have made a lot of progress that need to be considered.

Jochen Krause