On Sat, Jul 16, 2011 at 11:23 AM, Kenneth Gulbrandsoy
<kenneth.gulbrandsoy@xxxxxxxxx> wrote:
Update from the trenches of EMF:
I have completed my "proof of concept" on migrating uDig models to CDO. It is doable, but not without costs. I understand why people have been struggling the EMF models in the past though. There is a lot of complexity built into the model (ProjectImpl and MapImpl are really scary), which make them very difficult to understand and maintain.
I believe there are three general modifications done to generated EMF objects in the model, which forcing use off @generated NOT.
- Lazy object creation (in getXXX() methods), example ProjectImpl.getLayerFactory()
- Object locking and other synzhronization stuff
- Methods for object creation and destruction
So, what can we do to reduce the complexity?
Lazy object creation
This can be moved into the factory methods instead, leaving the generated getXXX() methods unchanged.
You may be correct here. The only real important part that needs to be lazy is loading maps and projects. If one map is loaded no other maps should be loaded. Same with Projects. It was a pretty big pain in the original version and I hope you can greatly reduce this complexity
Object locking and other synchronization stuff
If we migrate the models to CDO, most of the synchronization stuff can be removed. CDO ensures that each thread can access the model without the risk of race conditions resulting in memory inconsistencies. The only remaining locking required is when a specific access order is required by uDig processes.
Methods for object creation and destruction
These methods does not belong inside EMF objects. EMF objects are hard to understand just as they, adding more methods to them than strictly necessary is contra-productive. A set of utility classes should supply these methods instead.
This is going to be pretty tricky since when blocking you need to use a lock that does not lock the thread if the thread is the display thread, this is the purpose of ... can't remember the name of the lock, something like DisplayLock or something like that in the UI plugin. I am sure there is a way to work this but it could get tricky.
Conclusion
Implementing the changes described above, without breaking something in the EMF model, is hard. My experiment showed that and after careful consideration, my recommendation is unfortunately to rebuild the Project model from scratch, keeping the interfaces unchanged. As long as the interfaces in the model does not change, code depending on the model in a standard EMF way should not be effected. This allows us to redesign the inner parts of the model, implementing better synchronization support, reducing the complexity and thus making it easier to maintain.
I'm willing to do much of this work after my summer vacation, hopefully with the support of the PMCs and Jesse in particular.
Kill maim destroy. We might have to rename this to uDig 2.0 because it will break extensions but I think this is a long overdue.
Jesse
