[Geoserver-devel] Using versioned features as acceptence test for 2.4

In talking with Rob a couple of interesting points came up ... the useful one is this.

Adding an implementation of Feature that implements getVersion() is exactly the kind of change 2.4 is trying to support. If we can reuse Andrea's work as an acceptance test it will be of benefit. 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.

If I can ask everyone to tread carefully around these issues; we have a couple interested parties in the GeoTools mix - and this is the period of pain where compromise, patience and hard work are required :smiley:

Cheers,
Jody

My assumption (hope, perhaps) is that this will allow Andrea to deliver the capability via the OWS4 geoserver branch, which is aligned with 2.4, and we dont need to break any rules or risk dissipation of release efforts.

Enlighten me if I'm wrong here.

Also, I'm involved in a number of data standards development processes, and the issue of how versioning works is definitely tricky. I've been on the road and havnt been able to follow all the discussions, but is there a summary of how it is intended to reference versioned features via a WFS call?

If versioning information is pushed into the Application schema, then we need nothing special, but versioning may be a convenience API for transactions.

My idea is for versioning being an extension pattern for Feature Types (i.e. a history points to feature instances, decorating any available FeatureType with a common mechanism) - this fits quite well with the getVersion() method, but we may need to expose a virtual FeatureType "FeatureHistory" that we can query to access version history.

FYI This follows the Gazetteer profile pattern, where the Gazetteer Feature Type is really a metadata object for a collection of SI_LocationInstances that define the gazetteer contents,

Rob

Jody Garnett wrote:

In talking with Rob a couple of interesting points came up ... the useful one is this.

Adding an implementation of Feature that implements getVersion() is exactly the kind of change 2.4 is trying to support. If we can reuse Andrea's work as an acceptance test it will be of benefit. 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.

If I can ask everyone to tread carefully around these issues; we have a couple interested parties in the GeoTools mix - and this is the period of pain where compromise, patience and hard work are required :smiley:

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
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

Rob Atkinson ha scritto:

My assumption (hope, perhaps) is that this will allow Andrea to deliver the capability via the OWS4 geoserver branch, which is aligned with 2.4, and we dont need to break any rules or risk dissipation of release efforts.

Enlighten me if I'm wrong here.

Sure. ows4 branch is not a working Geoserver. It's lacking UI and configuration subsystem. It's an implementation of WFS 1.1 and a study
of the new Geoserver architecture to come.
It's something that you have to configure by hand, don't remember if either by coding its datastore entries by hand, or by writing a small
xml file (I believe it's the former), so it cannot be used by anything that should be user tested.
It serves its purpose well because it just have to be hit by the WFS 1.1
CITE tests, so not having a UI and a configuration subsystem is not relevant.
But for my work it's a roadblock.

Also, I'm involved in a number of data standards development processes, and the issue of how versioning works is definitely tricky. I've been on the road and havnt been able to follow all the discussions, but is there a summary of how it is intended to reference versioned features via a WFS call?

Sure, here: http://docs.codehaus.org/display/GEOS/Versioning+WFS
(if you're just interested in the implementation, see
http://docs.codehaus.org/display/GEOS/Versioning+WFS+-+Phase+one+implementation+proposal).

If versioning information is pushed into the Application schema, then we need nothing special, but versioning may be a convenience API for transactions.

Heh, that was my first idea as well.
But it won't work, encoding a generic filter against version information
would be a nightmare (encoding equality or simple comparison can be
done, the rest would be really complex). It simply does not fit the way
our jdbc datastore work, and I don't have time for a rewrite from scratch operation.

My idea is for versioning being an extension pattern for Feature Types (i.e. a history points to feature instances, decorating any available FeatureType with a common mechanism) - this fits quite well with the getVersion() method, but we may need to expose a virtual FeatureType "FeatureHistory" that we can query to access version history.

Well, we have history as svn has, as a list of commits. But you can
gather a full history of a feature as well.

Cheers
Andrea

Jody Garnett ha scritto:

In talking with Rob a couple of interesting points came up ... the useful one is this.

Adding an implementation of Feature that implements getVersion() is exactly the kind of change 2.4 is trying to support. If we can reuse Andrea's work as an acceptance test it will be of benefit.

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.

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?
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?

Cheers
Andrea

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

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

Andrea Aime wrote:

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.

Yes they are gone because for my work they were more trouble then they were worth. And yes I through away the old config system. But using some reflection and a spring brean i have already written I could bring back a new one in about an hour.

As for UI ( and this is just my opinion ), a pretty useful one could be written in a short time frame that is a lot simpler then the current one and just as useful if not more.

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.

Yeah, not much of the old code changed which was the whole idea. Howerver, there have been some significant changes. I do think we need a good way to track the changes that andrea is going to be making to the wfs code so that I can incorporate them onto the ows4 branch. I dont want this to be another complex-features nightmare.

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

We are not sure what the exact target will be. After ows4 is all done the next task is going to be documentation and coming up with a good game plan to bring this stuff home. I can see some stuff getting on sooner then later, some stuff waiting until later.

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?

You could, however... The bindings I have written parse requests straight to an emf model which has been generated from the wfs schema. To use them you would either have to use that model, or write bindings that would create objects in the old model.

Xml production however should slot it seemlessly.

Cheers
Andrea

-------------------------------------------------------------------------
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

!DSPAM:1004,4575a75e275092207481331!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org