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. *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. *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. I'm going to update the RFC shortly. Cheers, Kenneth 2011/7/15 Kenneth Gulbrandsoy <[email protected]> > Hi list and PMCs! > > Moovida and my self have been discussion what next generation resource > persistence in uDig might look like. We have started to write a RFC > proposal, which has the potential to add > > - Real project support, allowing users to move projects around > - Better concurrency control, using a main-stream transaction > framework, redusing the complexity of uDig model maintenance > - Real-time and fault-tolerant sharing of uDig resources (aka social > editing) > - And some other cool stuff > > The changes we are talking about are substantial. I have therefore already > started on some "proof of concept" work, migrating current uDig models to > CDO to see if this can be done without to much work. After 10 hours of work, > all models are migrated to CDO. This involved fixing dependencies on > interface now removed from Geotools, and changing dependencies from EObject > to CDOObject (extends EObject) and InternalEObject to InternalCDOObject. I > have not completed the migration yet, but I am able to add new projects and > maps to views using standard methods. > > When I have concrete results, I will push a branch to my udig-platform > clone <https://github.com/kengu/udig-platform> at github. > > Naturally, we would love some (a lot of) feedback on the RFC, which is > located here: > > > http://udig.refractions.net/confluence/display/UDIG/Next+generation+resource+persistence+in+uDig > > It is a big change (and probably a lot of work), a broad discussion about > pros and cons is therefore necessary before I can commit to this work. > > Cheers, > Kenneth Gulbrandsøy >
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
