With only a few weeks to go until Ganymede is released, already the sights are set on the future of Eclipse, referred to as E4. A recent E4 Summit debated the future goals and directions of where Eclipse is going in the future. InfoQ previously covered the scope of E4, but now it's starting to get more concrete. At this point, the E4 name is more of a code-name than a planned version number; and Eclipse 3.4 may be succeeded by 3.5 next year before E4 makes an appearance.
The main work item is to enable the Eclipse environment to run in a web browser rather than (necessarily) as a standalone application. Although RAP (webinar) has shown how it's possible to get a web-based rendering of a server-side Eclipse application (demo of workbench, demo of mail), the majority of the existing Eclipse workbench and IDE plugins are built to assume a specific hard-coding to the user interface.
There's an ongoing discussion on the future of SWT with the SWT Browser Edition. The current implementation of RAP uses the Qooxdoo AJAX library (demo) to render the UI remotely from the server. That might be a valid approach, or alternatively a cross-compilation technique like GWT might be used, although the underlying target might be a different in-browser VM (like Flex or Silverlight).
Another direction is to allow other languages to be used to write plug-ins, potentially allowing for scripting Eclipse in the future. Scala has been suggested as a language, although it's likely that some form of dynamic language like JavaScript or even JRuby will also be supported.
In order to permit the UI to be rendered in a web-browser with server-side storage, work has to be done to de-couple some of the singletons that assume a one-to-one user-to-workbench relationship. In addition, some of the synchronous APIs (like EFS) need to be migrated towards an asynchronous communications channel to deal with the inherent asynchronous nature of web-based systems. A new resource model is being discussed, hopefully avoiding some of the restrictions (like non-nested project hierarchies) that are built in to the current API, as well as a new application model.
There's been a lot of progress, not the least of which is that the E4 development process is a lot more open than before. However, bear in mind that this is all experimental; so there's no specific rules about what E4 should (or shouldn't) look like. There are some demos available if you want to download and try out the prototype code so far.
What do you think of the evolution from client-side IDE to web-based framework?
