Gabriels email
{panel} 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 instead of FeatureType.getDescriptors ():List. 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.
- 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.
- 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.
- port the rest of the main module
- port validation and wfs
- port wcs and wms
- 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 {panel}