Re: [eclipse-incubator-e4-dev] Eclipse Definition & presenting e4

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Hi Tom,

You've brought up some excellent questions.  Some are going to require
time for reflection but I wanted to answer you immediately with some initial
thoughts.

Let me try to address them in turn,
although I don't have answers for all of them:

> I read many things about the e4 but I'm missing
a strategic
> goal for e4.

The main goals for e4 are (in no particular order):
        1. Make it easier
to extend (use programmatically)
        2. Make it easier
to contribute to
        3. Create a new
technical foundation to ensure Eclipse remains relevant into the future
        4. Increase participation,
ensure community remains vibrant, diverse

Ok so those are pretty broad. We're presently going
through a phase of introspection ("What the heck is all this stuff
we have doing anyway?", "What are the long standing problems?",
"What have we learned that we'd like to do differently?").  Granted,
much of that has been from a technical perspective.  

The simple answer is, "e4 is the next gen of
the Eclipse platform. It should be what people think it needs to be, and
it will be what participants make it."  That makes messaging
inherently vague. Right now we're trying to understanding what people think
it needs to be. Maybe you have a certain vision and will influence that
direction.  

So far there's been some good discussion of the nature:

        In what ways are
we presently limiting the kinds of applications you can use Eclipse for?
        How do we see
the audience changing? Is RCP becoming even more relevant?  What about
the web?
        Can we simplify
the programming model?  
        Can we scale better?
        Can we open up
the language barrier to allow a wider audience for writing Eclipse plugins?
 (_javascript_ being a start)
        To what degree
must we remain backwards compatible?  How do we innovate but do that
at the same time?

One topic that we keep coming back to is better separation
of application/frameworks and presentation. Thus declarative styling via
CSS, XForms markup, modelling of the UI have all been hot topics. This
will enable RCP apps to apply proper branding, be less IDE'like, etc.

At the resource layer, there's been good discussion
on allowing more flexible resource layouts on disk, resources backed by
databases, handling very large resource sets, hiding projects from users,
and on.

> The current situation is that it is very difficult
to define Eclipse. If you
> ask someone what Eclipse is, the most likely answer will be "A
Java IDE".
> Let me cite the first sentence of eclipse.org
> 
> "Eclipse is an open source community whose projects are focused
on building
> an open development platform comprised of extensible frameworks, tools
and
> runtimes for building, deploying and managing software across the
> lifecycle."
> 
> I'm wondering if someone who has never heard "eclipse" before
knows what
> this sentence mean. In addition I cast doubt on the correctness of
this
> definition.

Its true we've mostly been focused on the technical
side, but well we're mostly all technical guys!  Your point is well
taken.

Then again I don't know if we've ever known what Eclipse
is or done a good job at communicating that.  The somewhat iconic
_expression_ "a framework for everything and nothing in particular"
comes to mind :)

> I think e4 is not only a new milestone for a technical platform, but
also a
> great opportunity to (re)define the scope of eclipse and its appended
> communication. I cannot understand why eclipse is limited to a "development
> platform".

We should differentiate "development platform"
meaning its an IDE vs. its an application framework for building a wide
variety of applications.  We want to reach a wider audience, both
in terms of kinds of applications, and kinds of programmers (skills required,
language required).  I agree our "messaging" needs a lot
of work. Its probably also true we haven't been thinking of things in as
much a strategic fashion as you're thinking.

> For me as a "RCP evangelist" of non-technical applications
it's sometimes
> very difficult to argument the use of eclipse as an application framework
> due to the missing of a (official) strategic adjustment regarding
> application development with the RCP framework. In addition I often
noticed
> that the community still divides SDK- and RCP-Development, especially
if it
> comes to discussions about the Workspace-API, Resources or the IDE-bundle
> (true to the maxim: "Either you develop tooling plugins for the
SDK or a
> RCP").

Some of that division is a result of the fact that
Eclipse was an IDE framework first, then an RCP platform after. As such,
some of the dividing lines were never clearly established. We're hoping
to improve that in e4.

> Another point is that many eclipse-projects cannot be reused in simple
non
> IDE RCP applications. That really hurts in Eclipse 3.x because I really
like
> the way eclipse behaves under the hood, but I don't like the complex
UI
> these projects provide (they are for nerds, not for non-techies),
the
> separation of "under-the-hood-functionalities" and the UI
is mostly a
> hopeless venture. 

This is definitely important for e4.  We clearly
need to enable a wider range of applications, and correspondingly, user
skills and interaction styles.  There've been some initial discussions
on how to do this.

> On the other hand some projects (e.g. ECF) demonstrate
> that such a separation is possible. The reuse of different components
is an
> important success-indicator; I'm sure that there are many developers
that
> would be happy if they could use the cool stuff other people develop
in a
> way where they don't need to suppress the debug-framework when they
want to
> use the Code-Highlighting of the xml-editor from WST (3.3). An orientation
> like a "seal of RCP approval" would be very helpful.

Its an interesting idea but I wonder how we'd ever
administer such a thing.

Then again its difficult to design for reuse without knowing how something
is to be reused.  Maybe folks coming forth with more interesting usage
scenarios will help drive this.
 
> But again: I have no clue about what the scope of e4, or even what
e4 is
> (the articles in the wiki handle very special things - no "meta-level").
-
> Maybe the points I mentioned are absolutely irrelevant, if so, please
excuse
> the noise. 

No noise at all, great questions some of which I certainly
hadn't considered and others may not have.

I don't think I really satisfactorily answered all
your questions.  Perhaps others could add more. I would like to view
this as a start of a longer conversation.  Please continue to share
your thoughts and questions.  Its a great form of particiation in
e4.  Welcome aboard! ;->

Best Regards,
Kevin McGuire