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
