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! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
