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 patterns...so 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?
Goals: self hosting with remote (same machine?) workspace (including remote builders, remote problems, and all the good stuff that goes with that).
- how to split?
- RAP -thin client with widgets on both ends
- Rich Client - RPC style communication
- Distributed - n tiers
- how do we enforce client/server plugin version compatibility
- do we use REST/RSS?
- synchronization as a first class citizen
- implicit vs. explicit APIs
- do we need tooling to detect problem patterns in user code?
- do we support disconnected operation?
- do we utilize streams? alternatively, how do we handle streams?
- stateless of stateful server?
- do we have a notion of sessions? can we handle server failover of these sessions?
- security coupled with identity