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. 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. 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 > > ------------------------------------------------------------------------------ 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
