Jody Garnett ha scritto:
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).
No, I don't think it'll be ignored.... it's just that the current geoserver user interface and configuration subsystem are the antithesis
of any effort to produce clean code. So I guess Justin threw them
out of the window in order to provide a cleaner base for the Geoserver
of the future.
There is common agreement among every geoserver developer I know that
the current UI and config subsystem need to be replaced.
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 -
It's not really so big a change, I can do it on geoserver trunk as well.
WFS modules are also changing too fast now that Justin is really testing
against the new CITE tests, so we would get one in the way of the other.
OWS4 will be a better place when the dust is settled off, but at the
moment it's a one man game.
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).
Initial WFS port from Justin hasn't been such a mess for him, mostly
cut, paste and fix. But I agree the more complex protocol using
branches could be developed on ows4 the day it becomes trunk.
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.
Sure.
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).
I fully disagree here. Once 2.4 gets in the state of the current 2.3,
that is relatively freezed, no big API changes, then, and only then,
Geoserver will consider moving over. Hopefully this will happen in
a few months.
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).
Jody, look at the last two months Geoserver developement. We're seeking
stability, not exciting new features at the moment.
Versioning is a small divesion, but then we'll have tiled map server, which is something to be worked on the geoserver side, and so on...
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.
I don't know... we're supposed to switch to the new xml stuff along with
wfs 1.1, that is, what will become geoserver 1.6 or eventually 2.0
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.
I'm subclassing postgis datastore, and already written 500 loc :-p
I guess I'll have a working datastore by mid of next week.
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?).
Cool, this means it'll be ready for 1.6
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.
I don't disagree, but it seems to mesomething for the future, not for today. When we go the new XML binders, all geoserver will switch.
Justin, I'm interested in your opinion here: shall I try to parse then
new requests with your binding framework or, since they just slight
variations of the old requests, I can go without problems with the old
one?
Cheers
Andrea
