Rob Atkinson wrote: > > AFAIK there are a few places where we need to understand how mature > the various branches are: > > 1) The GeoAPI supporting the General Feature Model (GFM) Reviewed, Implemented three times, not deployed. > 2) The DataStore API supporting GFM Reviewed, Implemented once, had a Factory/Builder mistake preventing serious deployment > 3) Existing DataStores ported to GFM (is the DataStore API is > backwards compatible, this should be trivial) Nothing, the factory/builder mistake means a we need to revisit the effected classes, and we would rather do that on as a community after getting agreement on a plan. If we leave the existing datastores out of this right now can that work? > 4) The rendering/serialisation components (renderer, GMLProducer) able > to handle existing (aka Simple Features Profile Level 0, shapefile, > rowset ) features via generic API I would like details about how much work was required to do this change on complex-features. > 5) Changes to SQL datastore I would fork the SQLDataStore from complex-features for this one. > 6) GML 3 support Do you have some work on this on the complex-features branch already? We need to treat GML3 as a seperate XML transformation classes, justin did have a run at generation of content as the inverse of GTXML, and the XDO based classes also support content generation. Once again lets ask gabriel and justin for details. > > Once 1-3 of these are in place, porting the complex-datastore can be > undertaken within its own little module. > > I propose to have a whiteboard session at FOSS4G/Lausanne on Thursday > sometime to systematically work through the decomposition of tasks, > identifying unit tests. Maybe I ought to be able to look at the three > code bases simultaneously and see all the issues, but I suspect I need > a bit of help from the people who have written the pieces. > > Rob A > > Justin Deoliveira wrote: >> Unfortunately, unless the development goes down on geotools trunk i >> don't see much point in us supporting it since it will never come home. >> With the fm branch and the recent migration strategy that has been >> drafted I think it is definitely possible to do on trunk, but is a lot >> more overhead for gabriel and rob as it would be much less work for them >> to continue hacking on complex-features because even the migration from >> complex-features to fm is not a clean one. >> >> More comments below. >> >> Jody Garnett wrote: >> >>> A thought has occurred to me that I would like feedback on from the >>> usual suspects (Gabriel, Justin, Rob). I am a bit worried about >>> continued development on the complex feature branch (even with >>> deadline pressures). So I would like to propose an idea. >>> >>> Starting points: >>> - We have the new feature model interfaces as part of >>> GeoAPI2.1-SNAPSHOT >>> - We have an implementation on the FM branch >>> >>> And the question: >>> Q: Can we implement a "Complex" DataStore on trunk, rather then see >>> it implmeented in the complex feature branch (again). >>> >> Gabriel can better comment, but as I said before there is a gap between >> complex-features and fm. However it is my impression that it would not >> be too much work to port over. Another issue is that Gabriel cannot pull >> this off until the full feature model implementation is in there which >> happens a bit later in the plan. We could move it up earlier and have >> two feature models lying around, but not sure how much I like that. >> >>> (To be clear this would not be an update to the existing datastores >>> - see previous migration plan for simple feature approved by Justin >>> on the wiki?) >>> >>> I think we could do this but I have some questions before I would >>> consider this a good idea: >>> Gabriel what extra support for GML writing/reading was required on >>> the complex feature branch? >>> Justin we have test cases for the implementations on the FM branch, >>> can we modified DataStore interface over as a DataStore2? >>> >> We have some test cases which we can move over, but not a ton. However I >> know you have been working a bit on fm in the last while, so you might >> have a better idea. >> >> The required changes to the DataStore interface should be minimal. The >> only really change would be the addition of methods that take the >> qualified name parameter as opposed to a single string. And I don't >> think it is even required for Complex Data Store. >> >>> Justin we would need to ensure this can be hooked up to your >>> GeoServer 1.5.x branch, is it up for the task? >>> >> Fortunately the complex-features branch does not require that many >> changes to GeoServer, almost all the work is in geotools. Porting the >> work will be pretty minimal, and we can always throw it in community. >> >>> Cheers, >>> Jody >>> >>> >>> ------------------------------------------------------------------------- >>> >>> Using Tomcat but need to do more? Need to support web services, >>> security? >>> Get stuff done quickly with pre-integrated technology to make your >>> job easier >>> Download IBM WebSphere Application Server v.1.0.1 based on Apache >>> Geronimo >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >>> >>> _______________________________________________ >>> Geotools-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> !DSPAM:1004,44fc9181158131194215290! >>> >>> >> >> >> > >
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
