Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled' work

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

I believe there's going to be a lot
of reluctance to introducing EMF into the platform.  Although maybe
not for good reason.  The problem with these kinds of discussions
is that they're so abstract that its easy for personal preferences or ignorance
(in this case, mine) to get in the way.  I've not done any in-depth
EMF work, I'd say I've more been acquainted with an EMF model or two but,
well you know, never really gotten to know them.  I'm sure their really
wonderful once you take the time, I'm embarrased to say that I've not.

Mind you, I know that for almost any
problem you mentioned to Ed, he believes EMF is the right solution to ("Ed,
about that global warming", "Well Kevin you see if we had a model
of all the carbon producing systems...")   :>

So maybe we should have a bake off.

I'd love to see a small prototype EMF
model which is functionally equivalent to what Eric has done so far.  Or
maybe to scope the effort, we chose a subset.  Then we can compare
on disk and in memory footprint, APIs, cost of extending in a specific
way, etc.  Regardless of which technology direction we end up choosing,
we (the platform UI team) would learn more about EMF, and the process would
facilitate concrete community discussion on the problem we're trying to
get our heads around. 

Regards,
Kevin

Ed Merks/Toronto/IBM@IBMCA
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

04/03/2008 03:40 PM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc	E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>, eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
Subject	Re: [eclipse-incubator-e4-dev] Initial discussion on the 'modelled'        workbench UI

Eric,

Comments inline below.


Ed Merks/Toronto/IBM@IBMCA
mailto: merks@xxxxxxxxxx
905-413-3265  (t/l 313)



eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx wrote on 04/03/2008 02:43:25
PM:

>
> The need for a model engine implementation that is more robust than
> 'ModelElement' is obvious. I share Ed's view that not having one
> will eventually lead to the less robust one being worked on until
we
> finally realize that we should have started with a real one (I call
> this 'reinventing the flat tire' because the result is always worse
> that some other 'real' wheel...;-).
>
> EMF is, of course, the first place to look but everything else is
> secondary here to ensuring that we make the correct technology
> choice first time. It certainly has one of the main prerequisites
to
> any answer; a community that's willing to pitch in and make it happen!!
>
> That being said there was some valid feedback when I was selling
> this story at EclipseCon and brought up using EMF as the base. It
> basically boils down to:
>
> 1) What's the overhead?
>
> Ed's comment "Using EMF models would be a boon because they would
> directly enable a rapidly growing stack of modeling technology."
is
> (to me) somewhat scary because most of our clients don't want a
> 'rapidly growing' anything, they want a rapidly -shrinking- platform
> (thus e4). The general fear is that EMF may already suffer from the
> 'bloat' and intra-package dependencies that we're trying to
> eliminate in the platform.

The rapidly growing stack is a stack of new plugins, not a rapid bloating
of the existing plugins.  Eclipse as a whole is a rapidly growing
stack in
exactly the same way.  Of course for many people, EMF is the SDK with
all
the tools bells and GUI whistles, but in the last release we decomposed
EMF
into a large number of small features so that clients can easily pick and
choose like a buffet.  From a runtime perspective, the important things
are
org.eclipse.emf.common (186,492), org.eclispe.emf.ecore (1,004,658),
org.eclipse.emf.ecore.xmi (211,907), and org.eclipse.emf.ecore.change (
80,430).  And even then, xmi is needed only if you need XML persistence,
and change only if you care to do change recording.

There are lots of interesting things that EMF can do in terms of minimizing
the amount of byte code in a generated model.  And of course, by providing
reflection-based serialization, you can effectively serialize all models
with the save 200K library.  An important lesson here is that when
looking
at the size of a library, also keep in mind how much the size of the down
stream code can be reduced as a result reusing the library.

>
> If we're anticipating having the model as a 'first class' concept
> then we're talking about placing it much nearer to the eclipse
> 'core' (equinox?). At this level size counts!! At minimum I'd expect
> that JFace would depend on it so we can provide 'modelled' JFace
> viewers, etc. Right now someone can simply get JFace/SWT and some
> GUI done...how much extra footprint would be needed to support EMF?

Size always counts! (And don't go readying terrible thoughts into my simple
words!  I hate when people do that.)  EMF is smaller than SWT.

Another question would be, how small would the alternative be?  And
also,
when a large portion of the Eclipse community has both EMF and the
potential EMF-like alternative installed, how big will the combined result
be?  As a general question, will the p2 platform really be smaller
or does
binary compatibility and adding new things mean it will be bigger?

I'm not even sure that by looking at jar sizes I'm even looking at the
right thing. In-memory footprint is important too, if not more important...


>
> 2) Can it mimic the current API?  < OK, this one's mine >
>
> This is not because I'm married to the current implementation but
> because the API is small and simple to understand (meaning broader
> acceptance generally). Exact matches aren't a requirement but I
> think that KISS counts here...

I know I had a discussion a while back on one of the newsgroups with
someone who expressed a dislike for model driven development.  He
got kind
of upset at me because I was a bit too tongue-in-cheek with him.  But
hey,
life is stressful and if you can't make light of stressful things, what
fun
would any of us have?
An important principle to keep in mind is that while each person may hand
write an API and think it's the best way and also each person is likely
to
argue that hand written code is simpler and easier to understand, that's
only true because they had to write every last tedious bit of it themselves
and hence understand it painfully well.  But have a look at someone
else's
hand written code and the simply loveliness of it all often seems less
clear.  The point is, that having regularized APIs that have predictable
structure and behavior across hundreds and even thousands of models, is
something not to be underestimated.

And you're probably going to hate this question, but a model without a
metamodel is a poor thing indeed, so if Ecore is not the metamodel for
the
new model, then what will be the metamodel? It's this metamodel that is
going to be a fundamental ingredient for bring order to the chaos...


>
> It's also 'open' in the sense that it's possible to add new
> properties into an object 'on the fly'. We're going to need this
> because in at least some cases (i.e. CSS management) we'll be
> 'importing' an external model of 'undefined shape' as well as likely
> being needed for the general scripting support.

Dynamic EMF will be a boon if this is an expected requirement.  Most
people
think of EMF as a code generator, but the runtime works just as well with
models for which no code is generated.  And of course models themselves
are
extensible too.  The need for scripting is is exactly one of the places
where the need for a metamodel arises and is where its power is best
demonstrated.

>
> I'd be happy to be involved in helping out on the investigations as
> well since I'm a true 'model driven GUI' zealot (ask anyone here!)
> and, to me, that means "Model comes first!!" because it's
the
> foundation for -all- the other work.

Wow.  Imagine if two zealots from slightly different religions combined
forces!

So now I can't resist point out that a metamodel is just a model, so you
can read in the metamodel as data, and then start to work with newly
created instances of that model exactly as if you had generated code for
it, i.e., you can read in a .ecore file with EClasses (think of it like
a
jar with .class files) and then create EObjects that are instance of that
EClass and work with that instance in a high level way (think of it like
a
java.lang.Object instance the .class, but with a more abstract level of
reflection).

>
> It's great to have the discussions underway!!

Woo hoo!


> Eric _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev