One of the motives for starting the e4 project was ensure that Eclipse remained a viable platform moving forward in a world where Web 2.0 technologies are gaining popularity and marketshare. Although Eclipse projects have taken steps to ensure a split between client(UI) and core code, there has inevitably been bleed through. This bleed through, if not addressed, could hinder Eclipse adoption in what are becoming Web 2.0 spaces.
- Where is the dividing line?
- Currently client code (in the guise of *.ui plugins) and server code (in the guise of *.core* plugins) are often tightly coupled by a plethora of listener mechanisms. Moving the UI to the web space, how do we accommodate this?
- What is the interface?
- In the 3.4 stream, all plugins are written in Java. The interface, typically, is the API contract exposed by the interface class files. Moving part of Eclipse onto the web, however, breaks this.
- How do we bridge the gap between web UI and java core? Is it some brand of RMI? Do we expose Eclipse internals via new REST APIs?
- Will we support multiple users?
- In enabling Eclipse to move to the web space it makes sense to make Eclipse support multiple clients. How do we achieve this?