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) 2) The DataStore API supporting GFM 3) Existing DataStores ported to GFM (is the DataStore API is backwards compatible, this should be trivial) 4) The rendering/serialisation components (renderer, GMLProducer) able to handle existing (aka Simple Features Profile Level 0, shapefile, rowset ) features via generic API 5) Changes to SQL datastore 6) GML 3 support 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
