Justin Deoliveira wrote: > I see a couple of issues with this approach. And I know that I have > voiced these before but I cant turn down the opportunity to do it > again :) That said I am glad to see the code appearing in an unsupported module (and used to test our Filter implementation) these are the first steps after all. Justin if I read your email correctly you are concerned about the big picture and making sure the complete plan is in place (even if it takes months or lacks funding)? > 1. The *hard* work occurs after the fact. Which means it is unlikely > that the major applications that need to support this ( GeoServer, > uDig ) actually will put in the effort. Not without *substantial* > funding, which I don't really see. Indeed; thanks for starting up your page with the check boxes .. is there any way we can make this more visible? I could not find it the other week when I went to look. > 2. It involves first changing to a new data access api, which means > two major api shifts, not just one. Well let's take the "DataAccess" page as a set of change requests for DataStore (because that is what it is). > 3. The new model will not receive the level of testing and qa needed > to be the core of the library. Switching to the new model will involve > more then just changing method calls and classes referenced in a > client app. The new model is semantically different from the old, so > client code will undoubetley fail as behaviour will be very different > between the two, behaviour that was not accounted for before the work > begins. > > 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.
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
