2011/8/5 Jesse Eichar <[email protected]> > I agree with Andrea. You can do a quick feasability study of changing the > package names to eu.udig but I want you to focus on the persistance task and > not get distracted. You are tackling a rather giant amount of work as it is > :).
Agree, the change to eu.udig is "off-topic", better to focus on the main purpose of the RFC. > > I took a look at the proposal. What is the ability to control the loading > of layer with CDO? I recently tried to fix a bug that is simply impossible > to accomplish with the current implementation and if we change the > persistence mechanism I would like to be sure we can fix that issue as well. > > CDO does not do anything to the way notifications are handled on the client side. That is entirely left to standard EMF. > > > Essentially the problem was that during the creation of a layer events were > raised that triggered resources in the catalog to be loaded when they should > not have been. I would like to be able to have good hooks into the loading > process so we can control it well. > Depending on where the EMF notification adapter is added, it should suffice to use Notifier.eSetDeliver(false)<http://download.eclipse.org/modeling/emf/emf/javadoc/2.4.2/org/eclipse/emf/common/notify/Notifier.html#eSetDeliver(boolean)> to consume any notifications made during construction of the layer. It sounds like we have to look into how this is handled today. Any factory methods should be able to handle this without any problems as long as the factory method knows which notifiers to disable notification delivery during construction. > > Also is it worth having such a complex solution? > IMHO this is actually a reduction in complexity, because EMF will become much more standard. The amount of modification of generated code required should be orders of magnitude less than what we have today (see my discussion in the "proof of concept" section in the RFC). > I know lots of people are extremely intimidated by the EMF model and would > like a simpler solution. Are there any alternatives? > As in alternatives to EMF? I don't know of any modeling and persistence framework with a better toolchain in Eclipse than the EMF framework toolchain. Any feedback from the community would be nice in that regard. Regardless of any preferences, the persistence framework we use must support modeling and code generation. Manual maintenance of all these interfaces are not feasible. That would require a major API change and a total rethink of how we persist uDig resources. Just my 2C. > I am not saying we should not go with CDO as I am comfortable with EMF, I > just want to make sure we look at other potential alternatives as well. > > Of course, a change as big as this require some level of scrutiny. I'll do some research on it. > Jesse > > > On Fri, Aug 5, 2011 at 12:36 AM, Kenneth Gulbrandsoy < > [email protected]> wrote: > >> Hi list! >> >> I have now updated the RFC >> proposal<http://udig.refractions.net/confluence/display/UDIG/Next+generation+resource+persistence+in+uDig> >> to >> reflect my posts, IRC chats and comments from the list, and I think it is >> good enough to be voted upon by the PMC and committers. So far, I have >> received positive feedback from Andrea (moodiva), Jody and Jesse. >> >> Since this RFC propose major (and overdue) changes to how uDig persist >> model resources, all uDig projects from version 1.2.2 and backwards will be >> broken. To remedy this, an uDig project import method is proposed, allowing >> old projects to be (automatically) converted and imported into the new >> persistence framework. >> >> *Be aware that if the RFC is approved, all community plug-ins will be >> affected because*: >> >> - uDig model will be refactored to *eu.udig.* *which breaks any >> existing dependencies on model objects >> - Plug-ins depending on non-standard EMF behavior of current models >> will be broken after the change >> >> As a result, all maintainers of community plug-ins are encouraged to read >> this RFC and give their feedback (and vote, even if they are not a PMC >> member or committer). This will help the PMC to make the best possible >> decision. >> >> Cheers, >> Kenneth >> >> 2011/8/4 Kenneth Gulbrandsoy <[email protected]> >> >>> Hi folks! >>> >>> I'm back on a decent internet connection, and have some e-mail reading >>> and writing to do. Anyways, see comments below. >>> >>> 2011/7/28 Jody Garnett <[email protected]> >>> >>>> I am looking forward to the updated proposal. >>>> >>>> >>>>> 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. >>>>> >>>> >>>> You could also rename the packages to eu.udig and make moovida happy >>>> (and me happy as well for consistency). >>>> >>> >>> Do you mean the *.project *.printing model packages? I think that is an >>> excellent idea. >>> >>> >>>> More seriously if we are going to take on a whack of instability I would >>>> like to keep the window short; I don't think we can be quick enough to set >>>> this up as a code sprint topic for foss4g. >>>> >>> >>> I agree. A code sprint would be really nice. I'm plan to attend the >>> sprint on IRC (if all goes to plan, I will attend foss4g next year). >>> >>> >>>> However I would like to be organised; be able to pass on a warning to my >>>> project managers and generally co-ordinate resources to make this >>>> efficient. >>>> >>> >>> Sure. Any preferences on how to do this? I will read up on how the code >>> sprint is organized. Where can I start writing up a code sprint topic for >>> foss4g? >>> >>> >>>> >>>> Jody >>>> >>>> _______________________________________________ >>>> User-friendly Desktop Internet GIS (uDig) >>>> http://udig.refractions.net >>>> http://lists.refractions.net/mailman/listinfo/udig-devel >>>> >>>> >>> Kenneth >>> >>> >> >> _______________________________________________ >> User-friendly Desktop Internet GIS (uDig) >> http://udig.refractions.net >> http://lists.refractions.net/mailman/listinfo/udig-devel >> >> > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel > > Kenneth
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
