Hi Gabriel, I see this debate is getting fired back up again :) I am not sure we will come to a concensus but here goes.
Gabriel Roldán wrote: > Actually the _work_ has to be 2.5. Just don't consider the early port as > unsupported module as something affecting the library (note the bug I'm > talking about is independent of the port form FM. It's just that Filter is > supposed to work on Object whilst its not). > > Jody's suggestion was to start the dance on 2.5, having it as unsupported on > 2.4 only helps on early catching the difficulties that'll show up. > > btw, talking on difficulties, I'm now even more convinced that making the old > model extend the new one is going to be such a mess that we'll get almost all > the library broken. Guess there could be a mitigation plan, like: > > - get the new model working > - port complex datastore > - do _not_ make geotools Feature extends geoapi Feature > - use FeatureAccess as the replacement for DataStore > - provide Adaptors from geotools -> iso > - deprecate geotools > - make geoserver work on FeatureAccess. > - port plugins, making them incrementally innecesary to access them through > the adaptor 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 :) 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. 2. It involves first changing to a new data access api, which means two major api shifts, not just one. 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. > > benefit: avoid about a month of work messing up with the inconsistencies and > regressions arising from a design nightmare. > See that making old extend new, so things keep "backward compatible" while > you > do the deprecation dance is _exactly_ what I did on complex-features branch. I too had experience on the complex-features branch. And my opinion about why it failed was that we naively expected people to just "want to switch over to the new model". Sure it was ugly, but the code that is ugly will be deprecated. > 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. 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 :). -Justin > Gabriel > > On Tuesday 06 February 2007 22:01, Chris Holmes wrote: >> Gabriel Roldán wrote: >>> On Tuesday 06 February 2007 19:21, Jody Garnett wrote: >>>> You are working on trunk I assume? >>> yup >> I was hoping feature model work would be 2.5. I guess that's just a >> dream, since 2.4 isn't even at release candidate and 2.3 is not at final? >> >> C >> >>>> The JPox stuff is there with test >>>> cases. I would like to move >>>> those test cases into *main* testing with simple collections of POJOs. >>> as far as I can tell, jpox doesn't compiles. >>> Yet, moving the test cases to trunk means moving the PojoPropertyAccessor >>> too, correct? >>> I also know I wrote a more complex test case sometime using the metadata >>> stuff, can't seem to find it right now... >>> >>>>> Gabriel I have gotten this to work against POJOs; I have met the bug >>>>> you are talking about before (and fixed it). I do hope it >>>>> has not returned ... >>> looks like :( >>> >>> So ok to fix it or not? I could just attach a patch to the jira issue if >>> you wish. >>> >>> Gabriel >>> >>>>> Jody >>>>> >>>>>> Hi all, >>>>>> >>>>>> sorry I seem quite these days. Beleave me I'm not, was just a bit sick >>>>>> and couldn't show up on yesterdays meeting. >>>>>> >>>>>> So I'm working on porting ISO Feature to trunk in an unsupported >>>>>> module. That's the easy part, integration the hard. >>>>>> >>>>>> As to get started, I would need our Filter implementation to work over >>>>>> ISO Feature. I know PropertyAccessor should do its work here, but it >>>>>> gets never called whatsoever, since Filter.evaluate(Object) is >>>>>> hardcoded to return false. >>>>>> >>>>>> So I would need permission to make Filter actually working over Object >>>>>> and hence making it work over ISO Feature being a matter of having the >>>>>> corresponding PropertyAccessor. >>>>>> >>>>>> Gabriel >>>>> ----------------------------------------------------------------------- >>>>> -- 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=12164 >>>>> 2 _______________________________________________ >>>>> Geotools-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>> ------------------------------------------------------------------------ >>>> - 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 > -- 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
