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? Or should we consider the communication an internal implementation detail which is not considered API?
- 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?
- Are the implications related to user authentication that need to be addressed globally?
- Do we care about scalability?
- If we are talking about multiple user support how many concurrent users do we want to support? Should the server be stateless?