[e4-dev] Some thoughts on the E4 compatibility story

[Brian de Alwis <briandealwis@xxxxxxxxx>]

I've been helping a company to move their application suite from a homegrown Swing-based application framework onto Eclipse.  In discussions, I've come to realize that our messaging around the compat layer is causing some confusion, and I think we should adapt our story around the compat layer.

This company's goals are to leverage the extensibility of the Eclipse platform to open up their suite to extension by their customers.  They're really excited by the CSS styling, DI, and the IEclipseContext.  Although their application suite is very well-suited to the E3.x UI model (views, editors), and they really like some of the E3.x UI technologies (e.g., cheat sheets, intro), our use of "compatibility layer" is off-putting: the implication is` that it's strictly for legacy applications that cannot be converted the E4 APIs, and not recommended for new green-field development.  Since their transition will be a big effort that they hope will carry their suite for the next 5-10 years, they don't want to move to something perceived as being "yesterday's technology".  But to implement what they want on a pure E4 foundation will effectively re-create the compat layer, which seems rather counter-productive.

In thinking about it a bit, I realized that the real achievement of the E4AP effort has been to split the Eclipse UI mechanisms from the UI policies.  Eclipse 3.x implemented a particular UI paradigm based around strong notions of views and editors, but it was a poor fit for apps that don't want to buy in to that UI paradigm.  With Eclipse 4, apps can implement their own UI paradigms, like I did for Kizby.  Seen in this light, the compat layer is really an implementation of such a UI paradigm.

My suggestion is that we should re-cast the compat layer as an "E3.x UI Paradigm" or "E3.x UI Policy layer" or "E3.x UI Framework" (vs platform), or something to that effect.  I personally like "framework" as a counterpoint to a "platform" — it implies any app written to the E4AP layer will likely require writing some plumbing to implement their own UI framework onto the minimalist policies defined by the platform.  Our E3.x UI framework then has two parts, one implementing the E3.x UI model using the E4 platform, and the other being a translation layer for older configuration methods into the E4 equivalents (e.g., the UI extension points, action sets).

To that effect, I think we should (and I will) start documenting how the compatibility layer (or whatever we call it) works, such as the expected tags on parts to distinguish an editor from a view, and how a more E4-focused plugin can safely interact with the E3.x UI Policy layer.  After all, it would be great for devs to be able to develop against the App.e4xmi.  Perhaps we should have a PerspectiveDescriptor?

[And while I've brought up naming, perhaps we should accept that the e4/E4AP distinction has been lost for ever, and we should just call the E4AP as "E4", like others are?]

Brian.