Hi list! I have updated the RFC proposal<http://udig.refractions.net/confluence/display/UDIG/Next+generation+resource+persistence+in+uDig> to reflect recent feedback.
Cheers, Kenneth 2011/8/5 Kenneth Gulbrandsoy <[email protected]> > > > 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
