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. > May also considered this in lite of the "Community Schema" GeoServer branch, lets take it up in the geoserver meeting. >> 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. > Yeah that was my question, can we run two feature models (even for this single plugin) rathen then have it on a branch for another round. >> (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. > Nope I have been on hold waiting for that plan of yours, so no work in a couple months at least. > 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. > I was thinking of a DataStore2 interface that used TypeName (so what you said), and possibly too a ComplexFeatureFactory as a dependency. >> 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. > So run me through this slowing: 1. probably make a new GeoServer gathering up some extra community modules (as per recent demo helloapp) 2. use of catalog.xml to punt the new datastore into the geotools catalog, will that be sufficient for geoserver to recognize it
Then we get a choice question: - wrap or adapt - teach the xml transofrm code how to output the features (this is what I need feedback from Gabriel on) However perhaps I am thinking this out too much, I need that answer on what complex-feature branch actually produces in terms of content range. 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
