Hi Andrea, going to try and give you a decent reply (think of this as a preview of the planning we will do in January, although given your concerns perhaps earlier) > As I stated, I cannot work on 2.4 because ows4 branch is just a WFS > 1.1 implementation, not a Geoserver I can ask a use to try out. See > my answer to Rob comments. It seems insane that the OWS4 branch has let go of a user interface and other creature comforts - I agree that it places the entire work in danger of being ignored (well it is already being ignored by you so the observation is moot).
The amount of effort going into making the kind of operations you are working on easy to produce on that branch makes it the obvious choice for you - but without a clear road map you are going to be wasting your time either way (either reinventing work done to make producing OWS operations easy, or work not done to wrap a user interface around the end product). Andrea I would ask for a road map during todays GeoServer meeting before writing OWS4 branch off ... something we also need to have for Rob's planning no doubt. Regardless during today's GeoServer meeting we should try and figure out when a version of GeoServer will work on 2.4. The answer my be build around Simone's schedule - as I recall, he needed his GCE replacement ready by the end of GeoTools 2.4. If the OWS4 branch makes it home in time fine, if not changing over to 2.4 is not a big deal (and the earlier the better). >> This kind of thing (extending the content GeoTools can work with) is >> exactly the kind of change that should not cause a ripple to the >> library, and instead we are left with a workaround. > Just for the sake of discussion and comprehension, how working on 2.4 > would benefit my work, besides the obvious that the required changes > should not go in a stable branch? Well you would be on trunk with other active developers, so when you ask for feedback you will have it in an more timely fashion. Normally being on trunk is advantageous over a branch since your work has a better chance of appearing in a release, and not falling out of sync with ongoing development. Even working on 2.3 I would advice you to stay away from deprecated methods (since alternatives are available to you in the 2.3). On the technical front you could package up your new content (feature+version) in a FeatureFactory and be done with it. You may also leverage justin's xml binding system if it seems appropriate (actually not having this available for defining and parsing your new requests and responses is the worst thing about this situtation). You may also enquirer if Justin still has plans to backport - he was aiming for basic functionality and documentation which he has since achieved. The other advantage is the work going into making oracle datastore (and indeed any datastore) easy to write and maintain. If I had you producing a JDBC baesd datastore I would be free to work on the supporing classes (that both you and justin would use). I have every confidence that your work would finish sooner then you wasting your time subclassing JDBCDataStore. Finally I should stress that 2.4 is a short release cycle, once it's targets are done it too will be locked down (in about a months time?). And then the real work will begin - but that is a tale for another time (and possible delayed until we can seek a round of funding). > I mean, even in 2.4 I would have to extend Feature and fix the GML > handlers to handle the newly added version attribute. > What other shiny new roads would the ongoing 2.4 work open for me? Binding+Writing as a replacement for your GML handling as well. Can you think of a nicer way to parse out your GML+version information when it is supplied during a request? Not to sound unusually bullish, but it is the right tool for the job. Cheers, Jody ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
