E4 summit debates on the future goals and directions of Eclipse
- Share
-
- |
Read later
My Reading List
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?
Too slow
by
Daniele Bufarini
Re: Too slow
by
Russell Leggett
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).
Technically, they could still do it in Java, even JavaFX, using the new applets. But Flex has shown itself to be pretty capable of a desktop like experience - especially if a lot of the real work is being done on the server.
Re: Too slow
by
Daniele Bufarini
Technically, they could still do it in Java, even JavaFX, using the new applets. But Flex has shown itself to be pretty capable of a desktop like experience - especially if a lot of the real work is being done on the server.
Yes, I might agree with you, except that... I have still to see a usable complex user interface - like the one of eclipse - done in Flex or JavaFX or whatever existing technology.
Even if the real work is being done on the server, you have to move data back and forth between the client and the server. In my experience you cannot design a web application as if it a desktop one, even if all your frameworks abstract you from the fact that your application is running on the web...
Re: Too slow
by
Russell Leggett
Firefox XUL
by
Ryan de Laplante
www.alphaworks.ibm.com/demo/flash/display/eclifox0
I don't understand why they wouldn't just use applets and swing (possibly including JavaFX script). By the time a web based Eclipse RCP is available the new super fast applet plugin will be publicly available. The only reason I can think of to tie Eclipse RCP to Firefox and not use Swing is because it would be admitting that Swing has caught up to SWT.
Dot Com burt 2.0
by
L. Mihalkovic
When everyone seems focussed on 'how', I ask 'why'?
Educational Content
Co-making Great Products
Jeff Patton May 22, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think