| Re: [e4-dev] Declarative UI |
|
Hallvard, Comments below. Hallvard Trætteberg wrote: Ed,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. 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. https://bugs.eclipse.org/bugs/show_bug.cgi?id=213988I 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...
|