Rob Atkinson wrote: > And in the meantime it sounds like Ben will have completed a local > spike and be ready with the patch :-) > > If the GSIP process takes so long, maybe we should have a single one > "fix everything" - seriously the effort that goes into breaking down > the big picture into small, regression testable changes needs to be > supported by a far more efficient GSIP process. I am curious to hear your ideas about "more efficient". > > Perhaps we need a GSIP-lite for backwards compatible changes that just > require minor adaptions, and another one for new functionality that > requires (or enables) throwing the old stuff away - like a new UI. > Perhaps, maybe we could add a sort of rating to a GSIP. Although I don't know much it would change things. Currently "minor" proposals tend to go through quite quickly, while "major" ones tend to be much more details and receive much scrutiny. > Rob > > On Wed, Jan 21, 2009 at 4:09 PM, Jody Garnett <[email protected]> wrote: >> Understood; we also need to balance this with helping Ben through the hoops >> :-) >> I had a good skype session with Rob and Ben yesterday and I will try and >> assist Ben as he documents what he intends to do. >> Let us both try to review this page as it takes shape; I worry that we have >> many different parties each imagining a different amount of work. >> Jody >> >> >> On Wed, Jan 21, 2009 at 10:36 AM, Justin Deoliveira <[email protected]> >> wrote: >>> Hey Jody, >>> >>> Up front I want to say that I realize we are putting this proposal though >>> many more hoops we do the standard proposal. But given 1) the order of >>> magnitude of the change and 2) the history of this topic, I think the extra >>> hoops are warranted. >>> >>> So in terms of what I think the proposal needs I think class diagrams and >>> system diagrams are of not much value here, what it needs is to outline the >>> nuts and bolts of what needs to be changed. >>> >>> A BEFORE/AFTER would be better, but I think too trivial to be useful. I >>> mean for myself and some others, we already know the api before and after, >>> so it is not of much value. What is of value is specing out the real >>> problems that will arise, that can only be flushed out during >>> implementation. >>> >>> So I would say pick a spike, and work though porting it over. I would say >>> either WFS GetFeature or WMS GetMap. And work down figuring out what need to >>> be changed and how. With that information in hand this proposal will have >>> enough weight to make it though. >>> >>> And one last note, an iterative approach is mandatory in my opinion. This >>> effort will yet again fail if it has to be a one shot thing, and far too >>> risky. >>> >>> -Justin >>> >>> Jody Garnett wrote: >>>> Hi Justin, >>>> >>>> I am going to restart the conversation on just this point - the proposal >>>> needs to be more explicit in order for anyone to vote on it. What level of >>>> detail are we looking for in this proposal; if this was design work we >>>> could >>>> ask for nice class diagrams as per your catalog proposal. This would be >>>> fine >>>> Ben could spend a week and bang up a proposal for us to review. >>>> >>>> I think my mistake was in starting with Gabriel's email and diagram; when >>>> I next see Ben online I will try and help him revise this page into his own >>>> words and with a series of tasks covering the classes that need to be >>>> modified. >>>> >>>> You stated that you would rather see a patch for a small section of the >>>> code base ported to the new api. Would the standard BEFORE/AFTER code >>>> examples do this for you ... or is that too trivial? >>>> >>>> The approach of working bottom up to my mind seems a good one; for every >>>> call that is changed to return a DataAccess; modules further down the chain >>>> can cast to a DataStore until that section of code is updated. >>>> >>>> Ben highlighted a few problem classes such as RetypingDataStore; I >>>> actually suspect he will need to create a second RetypingDataAccess and >>>> choose what class to instantiate based on an instanceof check of the >>>> origional. >>>> >>>> Is this the kind of detail you are expecting? >>>> >>>> Jody >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by: >>>> SourcForge Community >>>> SourceForge wants to tell your story. >>>> http://p.sf.net/sfu/sf-spreadtheword >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Geoserver-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> >>> -- >>> Justin Deoliveira >>> OpenGeo - http://opengeo.org >>> Enterprise support for open source geospatial. >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> >>
-- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
