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

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

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.

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?

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

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.

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.

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