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
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
(attachments)
