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
