Sorry to chime in even later. A few thoughts Ben Caradoc-Davies wrote: > Andrea Aime wrote: >> Ben Caradoc-Davies ha scritto: >>> I have renamed the DataAccess proposal and now propose it as GSIP 31. >>> http://geoserver.org/display/GEOS/GSIP+31+-+Use+DataAccess+API >> The general idea in the GSIP is fine, but it's a very, very big >> topic that requires changes in both GeoTools and GeoServer. >> So I'd say we need a linked improvement proposal in GeoTools >> as well, and a vote in both control commitees. > > Preliminary investigations indicate that only small changes are required > in GeoTools. DataAccess/Feature/FeatureType (DAFFT), which is what I > mean by "DataAccess API", is already well-supported in GeoTools. > Furthermore, as a library with a decoupled architecture, GeoTools is > amenable to extension, so I can readily add new builders and > implementations without breaking backwards compatibility. The problem > with GeoServer is its centralised resource management, which has not yet > undergone the DAFFT transition to the same extent as GeoTools, and is a > blocker of future development. This is why the proposal is restricted to > GeoServer. >
So my main problem with this paragraph is the notion that the DataAccess API is 'well supported' in GeoTools. Has it seen any real use in production? Has it been integrated in stable versions of any projects? The part of the switch that scares me is what happens after the classes have been changed over. I've been a part of a feature model change and a data api change, and they are easy to do in GeoServer. But the bitch is in the months after when lots of bugs pop up. So I guess the assurance more needed from my end is that there are tasked resources that we can assign issues to and have them fixed as quickly as possible. These will pop up probably until we hit 2.0.2. I want to be sure that the job is not seen as done when the data access api is on, for me that's only the very start of the job. > I anticipate that, at least for the first wave of changes, I may be able > to get by with changes to GeoTools as small as spot cleaning with a > little SimpleFeature Remover (TM). For example: > http://jira.codehaus.org/browse/GEOT-2270 > >> The second thing that is required for any GSIP to pass (both >> in GeoServer and in GeoTools) is resourcing. >> As far as I know OpenGeo has agreed to only provide code >> reviews for the changes that are going to happen, to make >> sure we don't regress (too much) in the existing functionalities >> while adding the new ones (and given the extensiveness >> of the change, even only code reviews will take a lot >> of time on our part, which means a significant financial >> investment anyways). Anyways, I'm not the one paying the >> bills on this one, Chris might want to chime in here ;-) > > I would be delighted if OpenGeo: > 1. Review the patches. > 2. Run CITE tests. > 3. Decide if performance is sufficient and no regressions are introduced. > 4. Commit the changes. > 5. The same ongoing support that is already provided. > >> Do you have enough resources to pull this up on your own? > All these are fine except I'm not sure on #5. If this introduces a bunch of bugs that no one is helping us fix we'll look in to backing out the changes. But that can easily be seen as much more support than we already supply. We are obviously willing to help fix a few bugs introduced, but we don't want to be left as the maintainers of a massive new work. It doesn't sound like this is what you're saying, it sounds like you are committed to help out for the indefinite future. But I just want to be clear. We will be looking at the patches more closely than others since they are core and cut across everything, and no matter what will introduce bugs. I wish our testing was good enough to catch most all of the potential bugs immediately, but it's not. > I believe so. I am now working full-time on this task. It is essential > for the success of my project that this work be completed. We can add > more developers if required, although it is my preference that they > continue on other areas (e.g. GeoTools app-schema). > When does funding on your project end? And are you able to task people on helping fix bugs until that time? I apologize if any of this comes across as negative, it's really just us evaluating risk and trying to minimize it as much as possible. This will be a great improvement for GeoServer, and we're excited to grow the community. best regards, Chris -- Chris Holmes OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
