Skip to main content
Jump to: navigation, search


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?
      • Comment (Scott Lewis): I would suggest using asynchronous messaging as a primitive rather than RPC (RMI), and allowing both the use of asynchronous as well as RPC/synchronous communication that either/both can be used in appropriate communications contexts. ECF has APIs for protocol independent messaging (via datashare) and RPC (via remote services). These APIs allow using either/both communication patterns in a transport-independent way (allowing providers to compete on performance, standards compliance, interoperability, etc). ECF also has authentication APIs useful for multi-user support and well-integrated with Equinox/JAAS.
  • 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?

Back to the top