>> >> By "forcing" clients to use the new model underneath the old we will >> have the same issues, but they will be flushed out up front. Not >> pushed off to the side for now and forgotten until later. > This is where I have a conflict with you on scope; I expect clients to > use the new interfaces (this means GeoServer and uDig) and no longer > import org.geotools.feature.Feature. We tried to "stagger" this sort of > change with the Filter API for GeoTools 2.3 and it did not work. > How did it "not work"? GeoServer successfully made the transition gradually, which was the whole point of keeping the old interfaces around, just deprecating them.
And how do you expect clients to just switch without a cycle of deprecation first? Last time I checked Feature has not been deprecated. > So by all means let's use the existing implementation (and for GeoTools > 2.5 make it implement SimpleFeature); but as part of making sure it > works as advertised we should use the GeoServer and uDig codebases to > hammer on the SimpleFeature api. >>> I seriously would recommend against that based on experience. There >>> are othey ways to provide backwards compatibility than abusing >>> hineritance that uggly. >> Can you suggest one that only involves a single api shift? I agree >> that providing an alternative model that is not related to the first >> is much cleaner, and much easier to pull off. >> >> Please, members of the udig and geoserver teams please speak up with >> your opinion. And if you think i am being unreasonable please just say >> so. But I dont see how a an app like GeoServer or uDig whose primary >> goal is striving toward stability can realistically rewrite half the >> code base against 1. a new feature model, and 2. a new data access api. > This get's into the steering document I am trying to write a draft of.... > GeoTools 2.4 All the prep for FM is done > - if that includes changes to DataStore API then so be it ... let's > establish scope. > GeoTools 2.5 change to an implementation of SimpleFeature *only* > - I expect uDig and GeoServer codebase to change there import statements > to SimpleFeature >> Take for instance ows4. I basically rewrote geoserver for all intents >> and purposes. And only a fraction of that work is coming back to the >> core, and it is coming back very slowly to give the app time to >> adjust. Imho this kind of approach is only acceptable for R&D and does >> not scale to the long term. >> >> End rant :). > Ah rant; > 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,45c90268157836309890654! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
