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. 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? 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). Note also: http://en.wikipedia.org/wiki/Mythical_Man_Month > (the GSIP misses a resourcing part, the "who does what" one). I have not seen a GSIP that includes such a section. I undertake to make the minimal changes that will allow DataAccess loading and encoding of WFS responses. I do *not* propose to support DataAccess in WMS or other services, but some movement towards this functionality will likely be a by-product of the main/wfs work. > Moreover, what happens if someone pulls the plug mid-way? > The changes should be incremental enough to allow us to > keep them in even if the entire switch is not complete. Changes will be designed to minimise impact on existing functionality, be incremental enough to preserve my sanity. And if the quality is not satisfactory, I trust that you will reject them. :-) Kind regards, -- Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au> Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia ------------------------------------------------------------------------------ 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
