[Geoserver-users] Some considerations on WEB-UI modularization

GeoServer GeoServer User
21

I know jesse has not had a chance to respond to the 2.3 and uDig based questions from Monday's meeting.
It seems that he is swamped and will not have a chance to play with us, and we should make plans accordingly
(on the bright side he was asking questions about improving some of the datastores, hopefully we can talk
to module maintainers in a bit if a plan takes shape).

Hum, I see problems here in the possible release date.
Forces:
* can we release 1.4.0 without modularizing the UI? Does it make sense?
  

Yes we can, it just means we have a module system. Can we include WCS as a community module yet? No ...
We should release 1.4.0 pronto, leaving trunk free for this work. All it means is that the modules
people create will function, but will not be able to pass the seven steps for GeoServer acceptance (of which
config and user interface are two).

It makes sense, it is not complete, but it makes sense.

* gt2 2.3.x wants to do a release soon, but it should be tested
   at least with geoserver and udig
  

uDig is out of the picture citing lack of resources and a different direction, we may be able to
temp them with the new grid coverage work, but I would like to have a talk about WCS Client
support with Simboss (and Richard?) first.

* geoserver won't really test the new features in 2.3.x until the wcs
  branch hits the trunk and everybody starts fiddling with it
  

Indeed, so I would like to get 1.4.x out of the way, and move trunk to 2.3 so we can start working
on it.

* wcs branch won't be merged onto trunk until 1.4.0 is out (or not?)
  

Indeed.

So it seems delaying 1.4.0 release will delay gt2 2.3.0 which in turn
would delay even more the feature model branch merge... oh my...
that's why I was concentrating on giving a modular face to our
current configuration system
  

understood, so lets get GeoTools 2.2 out the door and chase it down with GeoSever 1.4.0, I trust
uDig will continue to track this branch keeping it stable while GeoServer kicks 2.3 around for a bit.

A configuration system overhaul would take quite a bit of time, there's not
even a design around, and it would delay even more all the rest.
  

Indeed, that is why it is not being considered right now? At least by me ... lets evolve a configuration system
based on preference module (see Jesse's proposal) and if we want we can start switching existing modules
over to it. We do not have to do anything with WCS before 1.4.0 goes out, and it would be very nice
to have a 1.5.0 alpha with WCS out (with & GT 2.3) to demo at FOSS

I'm concerned :frowning:
  

I am happy, somebody else recognizes we need to nail down our roadmap and follow it to get through the
next little while. And heck it is thursday - what happened to the GeoTools 2.2 release?

Jody

22

I had hoped with the definition of a Preference module (see Jesse's proposal) we could try out two ideas:
1. An easy way for modules to externalize their settings and remain independent of database or file based persistence (death to data dir!)

I think completely killing the data dir would be silly, it's one of the more popular features, let's people upgrade easily and lets you pass a configuration to someone else. I'm all for allowing other kinds of persistence as well, but I think a nice, tightly defined file-based structure is important for anyone's who's actually _using_ geoserver instead of just developing it.

2. An experimental module to watch the JMX beans and save them (and version?) without client modules having a clue

But the first step is preference model :wink: Hi Jesse, hopefully you get to hack with us again soon.

Where is a link to this 'proposal' you speak of? I found this: http://docs.codehaus.org/display/GEOSDEV/Proposal+Preference+Store+Service but it lacks any technical explanation or example. I remember mention of it, and at first glance it felt a bit 'loose' from the perspective of a developer writing like a UI against it. It seemed fine for a community module, for an option for a new module to persist its stuff. But for our core stuff I'd like to see a more thought out API, exposed in a good rest interface, instead of a mush of preferences.

I think the main use case is to make it really easy to do the operations in:
http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog
I'd like to see an example of the preference store making a new featureType and reloading the catalog.

Chris

23

We would like to release 1.4.0 right away, but that geotools 2.2.0
release just never comes. I think we are at the point where we might
just release against an RC that worked.

-Justin

Jody Garnett wrote:

I know jesse has not had a chance to respond to the 2.3 and uDig based
questions from Monday's meeting.
It seems that he is swamped and will not have a chance to play with us,
and we should make plans accordingly
(on the bright side he was asking questions about improving some of the
datastores, hopefully we can talk
to module maintainers in a bit if a plan takes shape).

Hum, I see problems here in the possible release date.
Forces:
* can we release 1.4.0 without modularizing the UI? Does it make sense?
  

Yes we can, it just means we have a module system. Can we include WCS as
a community module yet? No ...
We should release 1.4.0 pronto, leaving trunk free for this work. All
it means is that the modules
people create will function, but will not be able to pass the seven
steps for GeoServer acceptance (of which
config and user interface are two).

It makes sense, it is not complete, but it makes sense.

* gt2 2.3.x wants to do a release soon, but it should be tested
   at least with geoserver and udig
  

uDig is out of the picture citing lack of resources and a different
direction, we may be able to
temp them with the new grid coverage work, but I would like to have a
talk about WCS Client
support with Simboss (and Richard?) first.

* geoserver won't really test the new features in 2.3.x until the wcs
  branch hits the trunk and everybody starts fiddling with it
  

Indeed, so I would like to get 1.4.x out of the way, and move trunk to
2.3 so we can start working
on it.

* wcs branch won't be merged onto trunk until 1.4.0 is out (or not?)
  

Indeed.

So it seems delaying 1.4.0 release will delay gt2 2.3.0 which in turn
would delay even more the feature model branch merge... oh my...
that's why I was concentrating on giving a modular face to our
current configuration system
  

understood, so lets get GeoTools 2.2 out the door and chase it down with
GeoSever 1.4.0, I trust
uDig will continue to track this branch keeping it stable while
GeoServer kicks 2.3 around for a bit.

A configuration system overhaul would take quite a bit of time, there's not
even a design around, and it would delay even more all the rest.
  

Indeed, that is why it is not being considered right now? At least by me
... lets evolve a configuration system
based on preference module (see Jesse's proposal) and if we want we can
start switching existing modules
over to it. We do not have to do anything with WCS before 1.4.0 goes
out, and it would be very nice
to have a 1.5.0 alpha with WCS out (with & GT 2.3) to demo at FOSS

I'm concerned :frowning:
  

I am happy, somebody else recognizes we need to nail down our roadmap
and follow it to get through the
next little while. And heck it is thursday - what happened to the
GeoTools 2.2 release?

Jody

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

!DSPAM:1004,44db2930160371194215290!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

24

On 10-Aug-06, at 8:09 AM, Chris Holmes wrote:

I think completely killing the data dir would be silly, it's one of the more popular features, let's people upgrade easily and lets you pass a configuration to someone else. I'm all for allowing other kinds of persistence as well, but I think a nice, tightly defined file-based structure is important for anyone's who's actually _using_ geoserver instead of just developing it.

On that same note, storing all the configuration information in memory and requiring a "reload" for new configurations is a repeat of the same mistake that ArcIMS made many moons ago, and one of the things that makes it an unpleasant beast to administer. Even more than performance, in or Mapserver/IMS comparison test, the issue of maintainability was far more important. The "instant on" aspect of the Mapserver deployment was found to be a huge advantage.

25

Paul Ramsey ha scritto:

On 10-Aug-06, at 8:09 AM, Chris Holmes wrote:

I think completely killing the data dir would be silly, it's one of the more popular features, let's people upgrade easily and lets you pass a configuration to someone else. I'm all for allowing other kinds of persistence as well, but I think a nice, tightly defined file-based structure is important for anyone's who's actually _using_ geoserver instead of just developing it.
    
On that same note, storing all the configuration information in memory and requiring a "reload" for new configurations is a repeat of the same mistake that ArcIMS made many moons ago, and one of the things that makes it an unpleasant beast to administer. Even more than performance, in or Mapserver/IMS comparison test, the issue of maintainability was far more important. The "instant on" aspect of the Mapserver deployment was found to be a huge advantage.
  

I'm under the impression that all the aspects discussed in this thread are not mutually exclusive.
So far we spoke about:
- more flexible configuration system when it comes to choosing the storage tecnology;
- ability to reconfigure geoserver by remote calls (be it JMX, Rest, SOAP and whatnot)
- modular web ui for configuration

Paul, can you give me some more input about the mapserver configuration system? What
makes it so compelling? (sorry for being ignorant in this matter).
We are not far from a decent SRS document :-p

Cheers
Andrea

26

A mapserver "service definition" resides in a single "map file" which describes all the information (connections, layers, styles) necessary to instantiate that service. Mapserver is called as a CGI program, with a map=/path/to/mapfile CGI parameter as part of the call (though this can be obscured through use of Apache aliases and other tricks for production use). So the Mapserver installation (the CGI executable and linking libraries) live completely separately from the configuration files. And, it is possible to redirect the installation to a new configuration just be changing the map= parameter on the CGI line. Because the "map file" is read on every invocation of the program (every map) deploying changes to configuration is as fast as hitting the "save" button on the text editor you are using for changing the map file.

On 10-Aug-06, at 12:05 PM, Andrea Aime wrote:

Paul Ramsey ha scritto:

On 10-Aug-06, at 8:09 AM, Chris Holmes wrote:

I think completely killing the data dir would be silly, it's one of the more popular features, let's people upgrade easily and lets you pass a configuration to someone else. I'm all for allowing other kinds of persistence as well, but I think a nice, tightly defined file-based structure is important for anyone's who's actually _using_ geoserver instead of just developing it.

On that same note, storing all the configuration information in memory and requiring a "reload" for new configurations is a repeat of the same mistake that ArcIMS made many moons ago, and one of the things that makes it an unpleasant beast to administer. Even more than performance, in or Mapserver/IMS comparison test, the issue of maintainability was far more important. The "instant on" aspect of the Mapserver deployment was found to be a huge advantage.

I'm under the impression that all the aspects discussed in this thread are not mutually exclusive.
So far we spoke about:
- more flexible configuration system when it comes to choosing the storage tecnology;
- ability to reconfigure geoserver by remote calls (be it JMX, Rest, SOAP and whatnot)
- modular web ui for configuration

Paul, can you give me some more input about the mapserver configuration system? What
makes it so compelling? (sorry for being ignorant in this matter).
We are not far from a decent SRS document :-p

Cheers
Andrea

27

Hi Chris

I had hoped with the definition of a Preference module (see Jesse's proposal) we could try out two ideas:
1. An easy way for modules to externalize their settings and remain independent of database or file based persistence (death to data dir!)

I think completely killing the data dir would be silly, it's one of the more popular features, let's people upgrade easily and lets you pass a configuration to someone else. I'm all for allowing other kinds of persistence as well, but I think a nice, tightly defined file-based structure is important for anyone's who's actually _using_ geoserver instead of just developing it.

Up one implementation can use a file system (aka a DataDirectory), but the idea prevents clustering and the like - it is not a good design.

Where is a link to this 'proposal' you speak of? I found this: http://docs.codehaus.org/display/GEOSDEV/Proposal+Preference+Store+Service but it lacks any technical explanation or example. I remember mention of it, and at first glance it felt a bit 'loose' from the perspective of a developer writing like a UI against it. It seemed fine for a community module, for an option for a new module to persist its stuff. But for our core stuff I'd like to see a more thought out API, exposed in a good rest interface, instead of a mush of preferences.

Chris I do not have time to make this proposal, when/if Jesse gets back he can try and explain better. But by definition if we are exposing a service for other modules (that we have not even met yet) to save their settings we must provide a "mush of preferences" ... providing structure should be done by the module writer who knows the structure.

I think the main use case is to make it really easy to do the operations in:
http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog

I'd like to see an example of the preference store making a new featureType and reloading the catalog.

That is another good topic (persistence of a catalog of resource references), but the intention of a preference store is not to replace the catalog .... sorry the scope is not clear. Lets wait until Jesse
can provide more details.
Jody

28

Paul Ramsey wrote:

A mapserver "service definition" resides in a single "map file" which describes all the information (connections, layers, styles) necessary to instantiate that service. Mapserver is called as a CGI program, with a map=/path/to/mapfile CGI parameter as part of the call (though this can be obscured through use of Apache aliases and other tricks for production use). So the Mapserver installation (the CGI executable and linking libraries) live completely separately from the configuration files. And, it is possible to redirect the installation to a new configuration just be changing the map= parameter on the CGI line. Because the "map file" is read on every invocation of the program (every map) deploying changes to configuration is as fast as hitting the "save" button on the text editor you are using for changing the map file.

Interesting the FROG people (who never got back to us) are doing a similar thing, using spring to assemble the beans needed to handle the service on a per call basis (under direction from the command line). I had not though of using apache to make that process look sane ... but it is an idea.

Jody