Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Declarative UI


Comments below.

Hallvard Trætteberg wrote:

Ed Merks wrote:
Given sufficient interest, it would not be all that difficult to create an eEMF.  For example, all the specialized lists are great for optimal performance, but a single list can emulated all possible behaviors quite nicely...  The Ecore plugin was a one point only 250K in size, but clients always want more and more!

Perhaps we should discuss what limitations are acceptable for eEcore? Like read-only EModelElements?
It's probably harder to enforce read-only than to leave it as is.  :-P
Only binary Resource serialization?
The binary serialization is very small footprint compared to the XML serialization, but even that's not large, i.e, XMI is 216,647, and of course it's a separate optional plugin.

Maybe there's a way to compile the EMF model to straight Java code (like we do for XSWT) and so retain the design-time modelling benefits and keep the small runtime size?  Or some other solution?
Some folks have generated plain old Java, but in the end, reflection, notification, XML persistence is something the majority of the clients end up needing...

In general, you would want these, but for each specific application the usage may be limited...
It's hard to provide the smörgåsbord approach. :-P
Tools for deploying mobile applications include an "obfuscation" step, where jars are trimmed by renaming, removing unneeded classes and methods etc.
Sounds scary!
If EMF was included in this step, together with the relevant application classes AND models, I bet the total size could be reduced a lot. (It's a bit like "partial evaluation", whereby a generic program is specialized to a specific set of data). Think of it: Even if you use reflection, you seldom change EClasses, so you could remove all setters.
I see what you mean, including removing the eSet methods.  Note too that there are patterns of code generation (Reflective feature delegation) that produce minimal byte code (at the expense of speed of course).
An interesting experiment would be to profile a "typical" EMF application and note which Ecore methods are used and calculate the necessary footprint.
So many good ideas, so little time.  Generally I focus my very limited time where there are clients who are for sure going to use something.  I did already look at enabling EMF for RAP and eRCP but the interest seems to be limited.
I would imagine that a runtime of less that 300K would be quite feasible.  There will need to be involved parties with definite intent to use such things though...  I've lost the ability to make the "If you build it they will come" approach scale to the present client base...

e4-dev mailing list

Back to the top