Hi, chiming in late as usual... (hem.. turned out to be a long post so be sit down...)
My thoughts about integrating app-schema and hence DataAccess into GeoServer are driven by mi vision, which I'm not sure if its the best one but here it goes. Of course we do need a plan. What I'd really would like to see is to rephrase all the geoserver code base in terms of DataAccess/Feature/FeatureType. For the most part it shouldn't be that hard, since GeoServer essentially shouldn't be doing a lot of that sort of resource handling by itself. But there're always details that'll hit us hard. What I mean is, ideally geoserver picks up a OWS request, performs a geotools request and encodes the result. That and configuration. Si it makes sense to me for geoserver to treat them all the generic way (DataAccess family) instead of the special case way (DataStore family). Truth is, GeoServer does a lot of tweaking to geotools feature related stuff, like having its own feature reader decorators etc. For instance, these are the number of references in geoserver trunk for each of the affected interfaces: SimpleFeatureType: 532 SimpleFeature: 527 DataStore: 128 FeatureCollection<SFT, SF>: 204 FeatureSource<SFT, SF>: 185 FeatureStore<SFT,SF>: 71 FeatureReader<SFT, SF>: 22 SimpleFeatureBuilder: 33 SimpleFeatureTypeBuilder: 20 I am not sure how many of those are going to be mechanic changes and how many will require additional thinking. Off the top of my head what I can think of is: - everything that needs to build a Feature/Type uses SimpleFeatureBuilder/SimpleFeatureTypeBuilder. We need generic Feature replacements for them that still makes for the improved implementations in case the target schema is "simple". Also, since everything assumes simple features, all the SimpleFeatureType specific methods are used (eg, SimpleFT.getAttributeDescriptors():List<AttributeDescriptor> instead of FeatureType.getDescriptors():List<PropertyDescriptor>. This means getting rid of all those assumptions imposes adding a lot of tests (eg, ResourcePool has no test case itself) but the hardest part is perhaps thinking if even adapting the code to FeatureType implies the assumptions in the code are still valid. - FeatureReader/FeatureCollection etc decorators need to be updated - There is no support in GeoTools for a lot of widely used utility methods to work on Feature/Type (eg, DataUtilities.subType, etc) - All and every GeoTools implementation of the above interfaces work on SFT/SF, a lot of them are abstract base classes geoserver extends (eg, DataFeatureCollection) - DataAccess is defined in terms of FeatureSource/Store/Locking, not FeatureWriter in there. If FeatureWriter is somewhat needed DataAccess will need to be reviewed. Afaik FeatureWriter as obtained from DataStore acts as an editable cursor and at the time of writing DataAccess it was not clear that was a very used/needed apprach in contrast to FeatureStore.add/modify/removeFeatures() If I had to start laying out a plan, I would say small steps, bottom up, a subsystem at a time (if only our "subsystems" were that well decoupled as they could...). And it would be something like the pseudo-plan bellow, but first a reasoning: if we're going to do this on trunk, which I think we should, we need to be aware that it implies a lot of deviation from 1.7.x, which is ok since trunk's goal is 2.0, but just be aware of the possible extra complexity in forward porting fixes from 1.7.x to trunk. General plan: divide the refactoring in per subsystem iterations, for each one refactor and add tests as required, make sure all CITE passes, cut a milestone. The attached geoserver modules dependency graph is meant to help picture this out. It does not contains transitive deps nor direct redundant ones for the sake of clarity. 0) get rid of as many deprecated classes as possible. Yes, there're a lot yet. Starting with the old style, servlet based services and friends. 1) port Catalog to DataAccess/Feature/FeatureType (DAFFT from now on :) ). This will force for changes both in geotools and in the geoserver classes using DataStoreInfo/FeatureTypeInfo etc, and may provide for a good sens of the actual effort required. 2) port the rest of the main module 3) port validation and wfs 4) port wcs and wms 5) port web (the new one, get rid of the old one) As you can see, this is not going to be a cheap process to accomplish. Yet, one that's worth going for imho. But I'm sure I'm missing a lot of details or even there might be another smarter approach, so please feel free to argument. best regards, Gabriel On Thursday 13 November 2008 09:17:19 pm Jody Garnett wrote: > You should be talking with Gabriel on the GeoServer list to sort out a > plan. I imagine the plan will be presented to that list as a GSIP > proposal thing. Gabriel went throught the process of introducing > DataAccess and DataAccessFactory into the GeoTools codebase ... I am not > sure what the best progression is to introduce it into GeoServer. > > We should continue further discussion on the GeoServer list; if there is > any API change required (as you start using DataAccess for real) please > let me know - it should be within the scope of Gabriels origional > DataAccess proposal. > > Jody > > Ben Caradoc-Davies wrote: > > Jody, > > > > I have performed the initial port of the app-schema DataAccess > > (formerly known as ComplexDataStore) to trunk. Although there is some > > support in DataAccessFinder for using SPI to find and load > > implementations of DataAccessFactory, this implementation is not used > > by GeoServer. > > > > How should we proceed? Would the GeoServer community like to support > > DataAccess providers, or should we work around this problem? The > > solution on the 1.6.x branch was to fork the wfs and web modules into > > wfs-c and web-c. Now that we have DataAccess, we can do better. > > > > Kind regards, > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Geoserver-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
<<attachment: geoserver_depgraph.png>>
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
