On Sat, Jul 16, 2011 at 11:23 AM, Kenneth Gulbrandsoy < [email protected]> 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
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
