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

[Ed Merks <merks@xxxxxxxxxx>]

Kevin,

Comments 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 06:40:36
PM:

>
> I believe there's going to be a lot of reluctance to introducing EMF
> into the platform.

Really, I wonder why you believe that?  So far there seems to be mostly
support in favor of reusing long established technology and experience.

> Although maybe not for good reason.

I suppose we can dismiss the bad reasons pretty quickly and then focus on
the 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.

Yes, human nature will always be what it is.  Just as the neighbour's grass
always looks greener, your own baby always seems cuter.  (I've figured the
greener grass thing out though.  It's because grass from an angle looks
greener than if you look straight down at it.  So the neighbours grass
looking greener is perspective thing than changes as soon as you walk over
and look closely to notice the bare earth and the infiltrating weeds.)


> 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.

Given that you can completely suppress EMF (EObject, EList, and so on) from
the model's API, you might even have met a few "closet" EMF models.  :-P

>
> 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...")   :>

Hehehehe.  It's true.  I remember Frank Budinsky and I would get asked if
EMF could be used for some problem or other and we'd be like "Well, if you
can model it, you can model it with EMF, so of course!".  But then we'd ask
ourselves, maybe we're just like porcupines who, when faced with a problem,
always conclude that sticking it with quills is the best solution.

>
> So maybe we should have a bake off.

As long as we don't end up comparing apple pies with orange tarts...

>
> I'd love to see a small prototype EMF model which is functionally
> equivalent to what Eric has done so far.

Yes, we'd definitely need to build a prototype to understand all the
implications.  I think Tom is going to help with that.  He understand the
platform's UI code much better than me, and he also has played with EMF
extensively.  So he's probably the best informed of all of us.

> Or maybe to scope the
> effort, we chose a subset.

Oh, can't we do it all at once? :-P

> Then we can compare on disk and in
> memory footprint, APIs, cost of extending in a specific way, etc.

Yes, and things like easy of use, flexibility, generality, speed of
execution.


> 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.

Yes, I think it's the only way.  Every time I've done one of these kinds of
things, people have needed new or different things and each time EMF ends
up being more flexible as a result.

The only think I don't quite understand with the bake-off suggestion, is if
we are actually comparing two viable alternatives, i.e., EMF to some
alternative to EMF, or just comparing before EMF and after EMF?  As I
mentioned earlier in the note chain, a model without a metamodel is only
half baked. (Doesn't that fit in nicely with the bake-off theme?  I just
love metaphors!)

>
> 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
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev