[Geoserver-devel] Planning the next few months (warning, long mail)

GeoServer GeoServer Developer
1

Hi all,
there are many things going in Geoserver, and I feel the need
for a clearer planning.

This mail is very long, I've written it to try and summarize
what I've heard in chats and mails, to understand what's going on,
dependencies timing and the like.

Here I start with what I know, with my point of view, in the hope to
steer a discussion about what needs to be done.

On the technology/feature plate now we have, at the moment:
* 1.4.x: this needs to be released, now, we can have other 1.4.x
    if the need arises (and it'll probably do).
* 1.5.x: this branch has been created as a side effect of releasing
    1.5.0beta1. Here we have new stuff, that is, WCS with its new
    functionality and configuration, but also changes to WMS that
    afaik do increase the number of WMS served raster formats and
    provide better control on quality/size side of the raster equation.
* versioned datastore and versioned WFS: in progress (on my disk...).
    This is best developed against Geotools trunk, because this way
    I could host the datastore in its most natural place and have
    space for the needed feature model changes.
* OWS4 branch: WFS 1.1 support, but also new service architecture
    that provides a nice and usable service API that's no more linked
    specifically to the servlet world, making it easier to reuse
    it from another Geoserver module. And, of paramount importance to
    me, finally an architecture that allow for both unit and integration
    tests without the need to run an external, preconfigured Geoserver
    (that is, we can have the tests in the build and add them easily).
* ingestion engine: GeoSolutions guys are planning a new tool to
    allow shapes, images and the like to be automatically imported and
    configured into Geoserver. This allows for continuous catalog
    update when new data comes in from external services.
* tiled WMS: this requires changes in both the gt2 renderer and
    a new module that builds on top on the current WMS I guess.
    Changes required in the renderer are not earth shattering, so
    I guess they could be handled in 2.3.x or 2.4.x once branched.
* trunk against trunk, that is, the request to have Geoserver trunk
    work against Geotools trunk.

Also, on the technology side, we should not forget:
* new UI: a new UI framework that does not make us mad every time some
    components of the UI needs to be changed
* new config: a new configuration framework that does not make us
    mad every time a new option, or a whole new service, needs to be
    added to Geoserver.
* authentication/authorization: it baffles me we don't see this more
    often on the ml, but hey, if you allow people to update data using
    WFS-T, this very people should be controlled. A single
    transaction/no transaction switch as now does not cut it in my
    opinion (it works fine only in the OFF position).
The three above are different, because they are more of a wish list
item than ongoing work. We should open wiki pages to plan a bit both
of them, I'm going to in order to discuss at least requirements.
Having a document to design and plan has worked fine for versioned ds
imho, so I want to repeat the experience with those two.

On the users plate, the ml shows us different kind of users:
a) people struggling to get out simple results, usually maps.
     These need more straightforward configuration (think ui and data
     directory issues), and possibly a new module where you can configure
     a web map context and boom, have your fancy smanshy OpenLayers page
     configured with it. Instant satisfaction for simple uses, that is.
b) people happy with the current setup, besides annoyances due to bugs.
c) people struggling to use current Geoserver in bigger enterprise
     scenarios. Things that keep on coming up on the ml lately are Oracle
     data store, connection pooling, and also a bit of clustering.
d) people needing more. Better feature model, map tiling, versioning,
     you name it.

a) and d) people would probably be happy to try something new
if it shows promise on their unfulfilled needs -> trunk people
b) people would stay on the most stable branch, and we need to
fix bugs in order to keep them happy -> 1.4.x people (even 1.5.x
if they happen to need coverages).
c) people are in the middle, we need to do significant changes to
the code base to satisfy them, yet they don't really need any new
functionality (connection pooling comes to mind). -> I'd say 1.5.x,
assuming it's ok to do an overhaul of connection pooling code
in gt2 2.3.x. A discussion and wiki page about this shall be
opened on the gt2 site.

It's also interesting to consider dependencies between various
stuff we mentioned here:
* Oracle data store fixes just needs a maintainer, or anyone willing
    to push fixes inside the gt2 code base (eventually by sponsoring
    them).
* 1.4.x general bug fixes just require users to hammer it, we'll
    try to fix what they find.
* 1.5.x requires developers other than GeoSolutions to start working
    on the branch and to try it out, and become familiar with the new
    modules, and of course users to hammer it as well.
* versioned WFS requires the datastore, which is better developed
    in gt2 trunk at the moment since it has a place for new modules
    and it's easier to introduce Feature changes (without too much
    fight with other developers, that is), changes in the GML
    encoders/decoders, and changes in the WFS protocol,
    which could either be based on the old WFS 1.0 code,
    or on the OWS4 branch.
    So, I'd say for this we need gs trunk on gt2 trunk. It would be nicer
    to have ows4 landed on trunk as well, but it's probably harder.
* OWS4 requires to stabilize and to be documented. Landing it on trunk
    requires to fix/wrap existing services so that they can be used with
    the new dispatch architecture. Also, it requires a UI and a config
    system, thought Justin says we can retrofit the old code as well.
* authentication would requires design, but also UI and configuration...
    so I'd say, let's have it land when the we have a decent UI and
    configuration to play against?
* ingestion engine: this too requires configuration, I guess it's in
    the interest of everyone have it deal with new UI and new config.

Then we have people asking for trunk on trunk. Current trunk does
not seem to be far from 2.4.x branching, but as far as I understand
people asking for trunk on trunk want more than what will be included
in 2.4.
So, I'd say, OWS4 should land asap on trunk in order to avoid loosing
it, trunk will then depend on 2.4.x, then we branch 1.6.x and then _if
and only if_ people willing to do fancier stuff agree on having a not
too bumpy gt2 trunk we can then have a real trunk on trunk stuff.
I'd also like to know what are the timing requirements of people that
will work on "trunk on trunk".

Tiling WMS should be a topic for both 1.5.x (against 2.3.x) or 1.6.x,
I guess it mostly depends on how OWS4 landing gets in the way.
For sure, when OWS4 lands, it should be a stop the world thing, with
all developers working on other branches or lending a hand in order to
move all the stuff to the new architecture.

This leaves out config and new ui thought, and dependent tasks.
The two require design, development and a stop the world change on
trunk when implemented. When shall we add those?
Doing them with the "trunk on trunk" would probably widen too much
the scope of changes going on, leading to too much instability.
Doing them in current trunk, that is, the stuff that should become
1.6.x, may have timing problem (aka, it seems we need to hurry?),
and besides that, with such a changes Geoserver should probably
jump on version number 2.0?

All in all, we have lots to manage, and very interesting stuff too,
but I don't see an obvious path from here to there when it comes
to handle OWS4, new UI, new config and trunk on trunk.
I guess OWS4 and trunk on trunk people should speak about their
timings and requirements, this may help clear matter a bit.

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:1023,457c3adc194291194215290!

2

Hi Andrea,

Good email!! I think it sums up were things are at / going quite nicely.
A few comments about the ows4 part of things.

* In terms of time lines, the official deliverable is due end of
January. So I wouldn't imagine any of this stuff coming home before
then. There is also much documentation to do. I fear if we start the
work before documentation is in an acceptable state it will get overlooked.

* In terms of performing the work happen, I don't quite agree with the
assessment "the world will have to stop". I think it is possible, and
probably a good idea to bring the work home in chunks. Also, I don't
foresee everything I have done making it to trunk. As an example, no
ows4 doesn't really have a config subsystem. However that doesn't it
mean it will be hard to hook the new wfs module to the old config system.

I have yet to come up with the exact steps, and will of course need some
feedback. but something like 1. hook up the new dispatch system to old
services, 2. replace old wfs with new wfs, ....

* The last thing is political. Bringing this stuff home will destabilize
the code base, there is no doubt about it. So understanding is going to
be needed from the developers who have strict time lines for stable
features that trunk will be an *unstable* place for a while.

-Justin

Andrea Aime wrote:

Hi all,
there are many things going in Geoserver, and I feel the need
for a clearer planning.

This mail is very long, I've written it to try and summarize
what I've heard in chats and mails, to understand what's going on,
dependencies timing and the like.

Here I start with what I know, with my point of view, in the hope to
steer a discussion about what needs to be done.

On the technology/feature plate now we have, at the moment:
* 1.4.x: this needs to be released, now, we can have other 1.4.x
    if the need arises (and it'll probably do).
* 1.5.x: this branch has been created as a side effect of releasing
    1.5.0beta1. Here we have new stuff, that is, WCS with its new
    functionality and configuration, but also changes to WMS that
    afaik do increase the number of WMS served raster formats and
    provide better control on quality/size side of the raster equation.
* versioned datastore and versioned WFS: in progress (on my disk...).
    This is best developed against Geotools trunk, because this way
    I could host the datastore in its most natural place and have
    space for the needed feature model changes.
* OWS4 branch: WFS 1.1 support, but also new service architecture
    that provides a nice and usable service API that's no more linked
    specifically to the servlet world, making it easier to reuse
    it from another Geoserver module. And, of paramount importance to
    me, finally an architecture that allow for both unit and integration
    tests without the need to run an external, preconfigured Geoserver
    (that is, we can have the tests in the build and add them easily).
* ingestion engine: GeoSolutions guys are planning a new tool to
    allow shapes, images and the like to be automatically imported and
    configured into Geoserver. This allows for continuous catalog
    update when new data comes in from external services.
* tiled WMS: this requires changes in both the gt2 renderer and
    a new module that builds on top on the current WMS I guess.
    Changes required in the renderer are not earth shattering, so
    I guess they could be handled in 2.3.x or 2.4.x once branched.
* trunk against trunk, that is, the request to have Geoserver trunk
    work against Geotools trunk.

Also, on the technology side, we should not forget:
* new UI: a new UI framework that does not make us mad every time some
    components of the UI needs to be changed
* new config: a new configuration framework that does not make us
    mad every time a new option, or a whole new service, needs to be
    added to Geoserver.
* authentication/authorization: it baffles me we don't see this more
    often on the ml, but hey, if you allow people to update data using
    WFS-T, this very people should be controlled. A single
    transaction/no transaction switch as now does not cut it in my
    opinion (it works fine only in the OFF position).
The three above are different, because they are more of a wish list
item than ongoing work. We should open wiki pages to plan a bit both
of them, I'm going to in order to discuss at least requirements.
Having a document to design and plan has worked fine for versioned ds
imho, so I want to repeat the experience with those two.

On the users plate, the ml shows us different kind of users:
a) people struggling to get out simple results, usually maps.
     These need more straightforward configuration (think ui and data
     directory issues), and possibly a new module where you can configure
     a web map context and boom, have your fancy smanshy OpenLayers page
     configured with it. Instant satisfaction for simple uses, that is.
b) people happy with the current setup, besides annoyances due to bugs.
c) people struggling to use current Geoserver in bigger enterprise
     scenarios. Things that keep on coming up on the ml lately are Oracle
     data store, connection pooling, and also a bit of clustering.
d) people needing more. Better feature model, map tiling, versioning,
     you name it.

a) and d) people would probably be happy to try something new
if it shows promise on their unfulfilled needs -> trunk people
b) people would stay on the most stable branch, and we need to
fix bugs in order to keep them happy -> 1.4.x people (even 1.5.x
if they happen to need coverages).
c) people are in the middle, we need to do significant changes to
the code base to satisfy them, yet they don't really need any new
functionality (connection pooling comes to mind). -> I'd say 1.5.x,
assuming it's ok to do an overhaul of connection pooling code
in gt2 2.3.x. A discussion and wiki page about this shall be
opened on the gt2 site.

It's also interesting to consider dependencies between various
stuff we mentioned here:
* Oracle data store fixes just needs a maintainer, or anyone willing
    to push fixes inside the gt2 code base (eventually by sponsoring
    them).
* 1.4.x general bug fixes just require users to hammer it, we'll
    try to fix what they find.
* 1.5.x requires developers other than GeoSolutions to start working
    on the branch and to try it out, and become familiar with the new
    modules, and of course users to hammer it as well.
* versioned WFS requires the datastore, which is better developed
    in gt2 trunk at the moment since it has a place for new modules
    and it's easier to introduce Feature changes (without too much
    fight with other developers, that is), changes in the GML
    encoders/decoders, and changes in the WFS protocol,
    which could either be based on the old WFS 1.0 code,
    or on the OWS4 branch.
    So, I'd say for this we need gs trunk on gt2 trunk. It would be nicer
    to have ows4 landed on trunk as well, but it's probably harder.
* OWS4 requires to stabilize and to be documented. Landing it on trunk
    requires to fix/wrap existing services so that they can be used with
    the new dispatch architecture. Also, it requires a UI and a config
    system, thought Justin says we can retrofit the old code as well.
* authentication would requires design, but also UI and configuration...
    so I'd say, let's have it land when the we have a decent UI and
    configuration to play against?
* ingestion engine: this too requires configuration, I guess it's in
    the interest of everyone have it deal with new UI and new config.

Then we have people asking for trunk on trunk. Current trunk does
not seem to be far from 2.4.x branching, but as far as I understand
people asking for trunk on trunk want more than what will be included
in 2.4.
So, I'd say, OWS4 should land asap on trunk in order to avoid loosing
it, trunk will then depend on 2.4.x, then we branch 1.6.x and then _if
and only if_ people willing to do fancier stuff agree on having a not
too bumpy gt2 trunk we can then have a real trunk on trunk stuff.
I'd also like to know what are the timing requirements of people that
will work on "trunk on trunk".

Tiling WMS should be a topic for both 1.5.x (against 2.3.x) or 1.6.x,
I guess it mostly depends on how OWS4 landing gets in the way.
For sure, when OWS4 lands, it should be a stop the world thing, with
all developers working on other branches or lending a hand in order to
move all the stuff to the new architecture.

This leaves out config and new ui thought, and dependent tasks.
The two require design, development and a stop the world change on
trunk when implemented. When shall we add those?
Doing them with the "trunk on trunk" would probably widen too much
the scope of changes going on, leading to too much instability.
Doing them in current trunk, that is, the stuff that should become
1.6.x, may have timing problem (aka, it seems we need to hurry?),
and besides that, with such a changes Geoserver should probably
jump on version number 2.0?

All in all, we have lots to manage, and very interesting stuff too,
but I don't see an obvious path from here to there when it comes
to handle OWS4, new UI, new config and trunk on trunk.
I guess OWS4 and trunk on trunk people should speak about their
timings and requirements, this may help clear matter a bit.

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

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

!DSPAM:1004,457c3cbf195654750375898!

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

3

Justin Deoliveira ha scritto:

Hi Andrea,

Good email!! I think it sums up were things are at / going quite nicely.

Thank you. I just wish an obvious scheduling would have come out
of the assessment, and it did not happen. Oh well, easy is no fun.

A few comments about the ows4 part of things.

* In terms of time lines, the official deliverable is due end of
January. So I wouldn't imagine any of this stuff coming home before
then. There is also much documentation to do. I fear if we start the
work before documentation is in an acceptable state it will get overlooked.

Fair enough

* In terms of performing the work happen, I don't quite agree with the
assessment "the world will have to stop". I think it is possible, and
probably a good idea to bring the work home in chunks.

Indeed. But when the new dispatch system hits trunk everybody will
have to go and study the new dispatch system philosophy, even if his
work area is handled thru wrapping (which is just a temporary measure btw, I don't want to keep new and old around for long, since to handle
both you have to know both).

I have yet to come up with the exact steps, and will of course need some
feedback. but something like 1. hook up the new dispatch system to old
services, 2. replace old wfs with new wfs, ....

This is where my head hurts when it comes to versioned wfs changes. If
I do them on wfs 1.0, we'll have to recode them, since ows4 handles both
1.0 and 1.1, right?

* The last thing is political. Bringing this stuff home will destabilize
the code base, there is no doubt about it. So understanding is going to
be needed from the developers who have strict time lines for stable
features that trunk will be an *unstable* place for a while.

Yeah, this is understood... well, we could consider bugs that came out
with the 1.4.x dispatch change and build tests for those, at least
we would stop everything that already came out. It would have
been good to add tests for them in 1.4.x if it only it wouldn't had
been so hard. Besides that, we have CITE, so at least we cannot
fail the basics.

Cheers
Andrea

4

On 10-Dec-06, at 8:55 AM, Andrea Aime wrote:

* tiled WMS: this requires changes in both the gt2 renderer and
    a new module that builds on top on the current WMS I guess.
    Changes required in the renderer are not earth shattering, so
    I guess they could be handled in 2.3.x or 2.4.x once branched.

Why do you perceive tiling as a re-implementation issue? I think the TileCache approach already being pushed by Metacarta shows that it's just a layering on top of existing rendering infrastructures. So WMS tiling should be handled as another layer on top of an (unchanged) render stack?

P

5

Paul Ramsey ha scritto:

On 10-Dec-06, at 8:55 AM, Andrea Aime wrote:

* tiled WMS: this requires changes in both the gt2 renderer and
    a new module that builds on top on the current WMS I guess.
    Changes required in the renderer are not earth shattering, so
    I guess they could be handled in 2.3.x or 2.4.x once branched.

Why do you perceive tiling as a re-implementation issue? I think the TileCache approach already being pushed by Metacarta shows that it's just a layering on top of existing rendering infrastructures. So WMS tiling should be handled as another layer on top of an (unchanged) render stack?

Yes, you could, and it can be work very fine.
At the minimum, we require the geotools renderer to stop moving labels
for each different rendering request, and this is in the pack of "properly supporting WMS-C", that is, just fix the current WMS and
make it usable to serve tiles with TileCache on top of it.

Supporting TMS in Geoserver is another matter. From where I stand,
if an admin is familiar with Apache and Python he would choose MapServer
or Mapnik as the backend anyways, unless he needs better looking maps.

On the contrary, an organisation using already Java may be uncomfortable
of fiddling with another piece of software, one using Microsoft stuff
would be probably even more scared away from having to install not one
but two foreign technologies.

Having around TileCache makes it less urgent to implement one in Geoserver, at the same time the implementation is already there and
quite nice and compact,
so re-coding it in Geoserver should not be a major effort either.

Cheers
Andrea Aime

6

With a new UI and config system, and OWS4, we will have to probably call it GeoServer 2.0. Actually we most definitely will because any other projects depending on GeoServer (if there are any) will have to make major changes to adapt.

I agree that changing everything at once is too risky, we should try and determine how much risk each component has associated with it so we can plan a good strategy. (risk in terms of potential bugs and loss of backwards compatibility to existing services). Some guesses on risk:

- OWS4: to my knowledge it's pretty major, and even with it passing cite tests there is still a lot tweaks we don't have regression tests for. Is it a full re-write, or just a reorganization? Justin will know.
- New UI and Config system: both kind of go hand in hand. I would label them as low to moderate risk because they are reasonably easy to test.
- Ingestion engine: Part of the new config system? It can probably go in earlier especially since it will most likely be completed first. I would label this as low risk.
- authentication/authorization. Hard to tell since this hasn't been planned out and there are no requirements yet.
- trunk on trunk: moving geotools versions always raises new issues. I would rank this as moderate to high risk, depending on how much has changed in the geotools versions.

We should dedicate tomorrow's meeting to this planning.

Thanks for starting the ball rolling on it Andrea.

Brent Owens
(The Open Planning Project)

Andrea Aime wrote:

Hi all,
there are many things going in Geoserver, and I feel the need
for a clearer planning.

This mail is very long, I've written it to try and summarize
what I've heard in chats and mails, to understand what's going on,
dependencies timing and the like.

Here I start with what I know, with my point of view, in the hope to
steer a discussion about what needs to be done.

On the technology/feature plate now we have, at the moment:
* 1.4.x: this needs to be released, now, we can have other 1.4.x
    if the need arises (and it'll probably do).
* 1.5.x: this branch has been created as a side effect of releasing
    1.5.0beta1. Here we have new stuff, that is, WCS with its new
    functionality and configuration, but also changes to WMS that
    afaik do increase the number of WMS served raster formats and
    provide better control on quality/size side of the raster equation.
* versioned datastore and versioned WFS: in progress (on my disk...).
    This is best developed against Geotools trunk, because this way
    I could host the datastore in its most natural place and have
    space for the needed feature model changes.
* OWS4 branch: WFS 1.1 support, but also new service architecture
    that provides a nice and usable service API that's no more linked
    specifically to the servlet world, making it easier to reuse
    it from another Geoserver module. And, of paramount importance to
    me, finally an architecture that allow for both unit and integration
    tests without the need to run an external, preconfigured Geoserver
    (that is, we can have the tests in the build and add them easily).
* ingestion engine: GeoSolutions guys are planning a new tool to
    allow shapes, images and the like to be automatically imported and
    configured into Geoserver. This allows for continuous catalog
    update when new data comes in from external services.
* tiled WMS: this requires changes in both the gt2 renderer and
    a new module that builds on top on the current WMS I guess.
    Changes required in the renderer are not earth shattering, so
    I guess they could be handled in 2.3.x or 2.4.x once branched.
* trunk against trunk, that is, the request to have Geoserver trunk
    work against Geotools trunk.

Also, on the technology side, we should not forget:
* new UI: a new UI framework that does not make us mad every time some
    components of the UI needs to be changed
* new config: a new configuration framework that does not make us
    mad every time a new option, or a whole new service, needs to be
    added to Geoserver.
* authentication/authorization: it baffles me we don't see this more
    often on the ml, but hey, if you allow people to update data using
    WFS-T, this very people should be controlled. A single
    transaction/no transaction switch as now does not cut it in my
    opinion (it works fine only in the OFF position).
The three above are different, because they are more of a wish list
item than ongoing work. We should open wiki pages to plan a bit both
of them, I'm going to in order to discuss at least requirements.
Having a document to design and plan has worked fine for versioned ds
imho, so I want to repeat the experience with those two.

On the users plate, the ml shows us different kind of users:
a) people struggling to get out simple results, usually maps.
     These need more straightforward configuration (think ui and data
     directory issues), and possibly a new module where you can configure
     a web map context and boom, have your fancy smanshy OpenLayers page
     configured with it. Instant satisfaction for simple uses, that is.
b) people happy with the current setup, besides annoyances due to bugs.
c) people struggling to use current Geoserver in bigger enterprise
     scenarios. Things that keep on coming up on the ml lately are Oracle
     data store, connection pooling, and also a bit of clustering.
d) people needing more. Better feature model, map tiling, versioning,
     you name it.

a) and d) people would probably be happy to try something new
if it shows promise on their unfulfilled needs -> trunk people
b) people would stay on the most stable branch, and we need to
fix bugs in order to keep them happy -> 1.4.x people (even 1.5.x
if they happen to need coverages).
c) people are in the middle, we need to do significant changes to
the code base to satisfy them, yet they don't really need any new
functionality (connection pooling comes to mind). -> I'd say 1.5.x,
assuming it's ok to do an overhaul of connection pooling code
in gt2 2.3.x. A discussion and wiki page about this shall be
opened on the gt2 site.

It's also interesting to consider dependencies between various
stuff we mentioned here:
* Oracle data store fixes just needs a maintainer, or anyone willing
    to push fixes inside the gt2 code base (eventually by sponsoring
    them).
* 1.4.x general bug fixes just require users to hammer it, we'll
    try to fix what they find.
* 1.5.x requires developers other than GeoSolutions to start working
    on the branch and to try it out, and become familiar with the new
    modules, and of course users to hammer it as well.
* versioned WFS requires the datastore, which is better developed
    in gt2 trunk at the moment since it has a place for new modules
    and it's easier to introduce Feature changes (without too much
    fight with other developers, that is), changes in the GML
    encoders/decoders, and changes in the WFS protocol,
    which could either be based on the old WFS 1.0 code,
    or on the OWS4 branch.
    So, I'd say for this we need gs trunk on gt2 trunk. It would be nicer
    to have ows4 landed on trunk as well, but it's probably harder.
* OWS4 requires to stabilize and to be documented. Landing it on trunk
    requires to fix/wrap existing services so that they can be used with
    the new dispatch architecture. Also, it requires a UI and a config
    system, thought Justin says we can retrofit the old code as well.
* authentication would requires design, but also UI and configuration...
    so I'd say, let's have it land when the we have a decent UI and
    configuration to play against?
* ingestion engine: this too requires configuration, I guess it's in
    the interest of everyone have it deal with new UI and new config.

Then we have people asking for trunk on trunk. Current trunk does
not seem to be far from 2.4.x branching, but as far as I understand
people asking for trunk on trunk want more than what will be included
in 2.4.
So, I'd say, OWS4 should land asap on trunk in order to avoid loosing
it, trunk will then depend on 2.4.x, then we branch 1.6.x and then _if
and only if_ people willing to do fancier stuff agree on having a not
too bumpy gt2 trunk we can then have a real trunk on trunk stuff.
I'd also like to know what are the timing requirements of people that
will work on "trunk on trunk".

Tiling WMS should be a topic for both 1.5.x (against 2.3.x) or 1.6.x,
I guess it mostly depends on how OWS4 landing gets in the way.
For sure, when OWS4 lands, it should be a stop the world thing, with
all developers working on other branches or lending a hand in order to
move all the stuff to the new architecture.

This leaves out config and new ui thought, and dependent tasks.
The two require design, development and a stop the world change on
trunk when implemented. When shall we add those?
Doing them with the "trunk on trunk" would probably widen too much
the scope of changes going on, leading to too much instability.
Doing them in current trunk, that is, the stuff that should become
1.6.x, may have timing problem (aka, it seems we need to hurry?),
and besides that, with such a changes Geoserver should probably
jump on version number 2.0?

All in all, we have lots to manage, and very interesting stuff too,
but I don't see an obvious path from here to there when it comes
to handle OWS4, new UI, new config and trunk on trunk.
I guess OWS4 and trunk on trunk people should speak about their
timings and requirements, this may help clear matter a bit.

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:1023,457c3adc194291194215290!

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

7

Brent Owens ha scritto:

With a new UI and config system, and OWS4, we will have to probably call it GeoServer 2.0. Actually we most definitely will because any other projects depending on GeoServer (if there are any) will have to make major changes to adapt.

I agree that changing everything at once is too risky, we should try and determine how much risk each component has associated with it so we can plan a good strategy. (risk in terms of potential bugs and loss of backwards compatibility to existing services). Some guesses on risk:
We should dedicate tomorrow's meeting to this planning.

...

I agree with most of the reasoning, there's only one catch that stops
me from actually considering doing new config and new ui before OWS4 landing: OWS4 is the only branch that really allows unit and integration
testing without the need to set up a separate geoserver running during
the test.

Justin, I haven't checked, so I'm curious: would be it easy to
port the "unit testability" approach back to trunk without the rest?
If we do this, it would allow us to add unit tests before OWS4
lands and hopefully make new dispatch system landing less painful.

What do you think?
Cheers
Andrea

8

Andrea Aime wrote:

Brent Owens ha scritto:

With a new UI and config system, and OWS4, we will have to probably
call it GeoServer 2.0. Actually we most definitely will because any
other projects depending on GeoServer (if there are any) will have to
make major changes to adapt.

I agree that changing everything at once is too risky, we should try
and determine how much risk each component has associated with it so
we can plan a good strategy. (risk in terms of potential bugs and loss
of backwards compatibility to existing services). Some guesses on risk:
We should dedicate tomorrow's meeting to this planning.

...

I agree with most of the reasoning, there's only one catch that stops
me from actually considering doing new config and new ui before OWS4
landing: OWS4 is the only branch that really allows unit and integration
testing without the need to set up a separate geoserver running during
the test.

The more I think about it the more I think that better testing
procedures should be made paramount to anything else. For instance, part
of the reason that geoserver is scared of geotools trunk is because
without decent automated test coverage there is no way to manage changes
on geootools trunk, except for ignore them on a stable branch.

Justin, I haven't checked, so I'm curious: would be it easy to
port the "unit testability" approach back to trunk without the rest?
If we do this, it would allow us to add unit tests before OWS4
lands and hopefully make new dispatch system landing less painful.

Hmmm, I would have to look into it but I am pretty sure it would be
possible, But part of the reason why it is much easier on ows4 branch is
because ui and config have been thrown away. I don't see the config
being much of a problem, but getting the struts stuff to start up would
probably be tricky.

What do you think?
Cheers
Andrea

!DSPAM:1004,457d975621501362196140!

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

9

Justin Deoliveira ha scritto:

Andrea Aime wrote:

Brent Owens ha scritto:
I agree with most of the reasoning, there's only one catch that stops
me from actually considering doing new config and new ui before OWS4
landing: OWS4 is the only branch that really allows unit and integration
testing without the need to set up a separate geoserver running during
the test.

The more I think about it the more I think that better testing
procedures should be made paramount to anything else. For instance, part
of the reason that geoserver is scared of geotools trunk is because
without decent automated test coverage there is no way to manage changes
on geootools trunk, except for ignore them on a stable branch.

Yeah, indeed.

Justin, I haven't checked, so I'm curious: would be it easy to
port the "unit testability" approach back to trunk without the rest?
If we do this, it would allow us to add unit tests before OWS4
lands and hopefully make new dispatch system landing less painful.

Hmmm, I would have to look into it but I am pretty sure it would be
possible, But part of the reason why it is much easier on ows4 branch is
because ui and config have been thrown away. I don't see the config
being much of a problem, but getting the struts stuff to start up would
probably be tricky.

During the last two months I did not see many troubles with the UI,
but lots coming from specific datastores and from all the extension
we did allow beyond simple OGC stuff. I did lots of fixes without a
test and man this is scary.
So I would be happy to have code + config testable and forget about UI.

Cheers
Andrea

10

Justin, I haven't checked, so I'm curious: would be it easy to
port the "unit testability" approach back to trunk without the rest?
If we do this, it would allow us to add unit tests before OWS4
lands and hopefully make new dispatch system landing less painful.

Hmmm, I would have to look into it but I am pretty sure it would be
possible, But part of the reason why it is much easier on ows4 branch is
because ui and config have been thrown away. I don't see the config
being much of a problem, but getting the struts stuff to start up would
probably be tricky.

During the last two months I did not see many troubles with the UI,
but lots coming from specific datastores and from all the extension
we did allow beyond simple OGC stuff. I did lots of fixes without a
test and man this is scary.
So I would be happy to have code + config testable and forget about UI.

Yes, since we're going to drop the struts UI anyways we don't need to spend a bunch of time getting it set up for testing. We just need it to start up when we distribute it. But we don't need it to be up for the testing environment.

Chris

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

!DSPAM:1003,457dca88161421460912952!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org