[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] RFC in progress: Next generation resource persistence in uDig
|
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
<kenneth.gulbrandsoy@xxxxxxxxx>
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.
Naturally, we would love some (a lot of) feedback on the RFC, which is located here:
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
