[Geoserver-devel] gsip 22 - community modules updated (formerly named extensions)

GeoServer GeoServer Developer
1

Hi all,

I have revamped the extensions/community module GSIP:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I have taken into account Jody's feedback, and also some of the conversation that has taken place over IRC while I was away.

Please look over again and provide any more feedback, or comment on things you don't like or are missing.

I have also moved GSIP 17 to rejected, since its now incorporated into GSIP 22.

Thanks,

-JD

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

2

Justin Deoliveira ha scritto:

Hi all,

I have revamped the extensions/community module GSIP:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I have taken into account Jody's feedback, and also some of the conversation that has taken place over IRC while I was away.

Please look over again and provide any more feedback, or comment on things you don't like or are missing.

Well done. A few comments:
* I don't see any reference to signing the contribution
   agreement. When does this happen? We have three choices:
   - when getting commit access in the community area
   - when graduating to extension
   - when graduating to core
   Imho core module shall be covered. Probably extensions too,
   since we are distributing them. Community, meh, let's
   avoid this requirement and allow people to contribute
   without that extra headache?
* Imho the wording for the demotion from extension/core
   to community should be more direct: once the maintainer
   steps down the destiny of the module is in the PSC hands,
   which will evaluate if it's good, quiet, whatever is
   deemed necessary to keep in in the supported land
* community and extensions do have a maintainer.
   Person or company? What about core modules, who's
   the maintainer for them? the PSC itself? Seems fitting,
   if you want to have a seat on the PSC you take some
   of the onus of keeping the boat afloat (aka
   "with great power comes great responsibility")
* in the extension process you say:
   "A license called '<module>-LICENSE.txt' which
   contains the license for the extension". You mean,
   stuff like reporting usage of Apache modules and
   the like? I mean, the extension module should be
   GPL'd no? Or else, maybe not, but as things are
   today, it's very hard to develop a module that does
   not link to one of our's GPL'ed classes
* typo: "The more t4est coverage a community module
   the more credibility it gets." t4est -> test

Provided the contribution agreement and wording
for demotion of extension/core are taken care of,
assume I'll vote +1 (since I won't be around next
meeting).

Cheers
Andrea

3

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi all,

I have revamped the extensions/community module GSIP:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I have taken into account Jody's feedback, and also some of the conversation that has taken place over IRC while I was away.

Please look over again and provide any more feedback, or comment on things you don't like or are missing.

Well done. A few comments:
* I don't see any reference to signing the contribution
  agreement. When does this happen? We have three choices:
  - when getting commit access in the community area
  - when graduating to extension
  - when graduating to core
  Imho core module shall be covered. Probably extensions too,
  since we are distributing them. Community, meh, let's
  avoid this requirement and allow people to contribute
  without that extra headache?

Agreed, i think we want to keep the bar for community modules as low as possible. Signing a contributor agreement is now a req for promoting a community module.

* Imho the wording for the demotion from extension/core
  to community should be more direct: once the maintainer
  steps down the destiny of the module is in the PSC hands,
  which will evaluate if it's good, quiet, whatever is
  deemed necessary to keep in in the supported land

I have broken this out into its own section with some process and requirements for demoting a module. Should be move explicit now.

* community and extensions do have a maintainer.
  Person or company? What about core modules, who's
  the maintainer for them? the PSC itself? Seems fitting,
  if you want to have a seat on the PSC you take some
  of the onus of keeping the boat afloat (aka
  "with great power comes great responsibility")

I like this idea for sure... but i am not sure it has to be explicit. If anyone is an active maintainer of core modules, chances are they are already on the PSC, and if not I would say there is more a problem with the PSC process.

* in the extension process you say:
  "A license called '<module>-LICENSE.txt' which
  contains the license for the extension". You mean,
  stuff like reporting usage of Apache modules and
  the like? I mean, the extension module should be
  GPL'd no? Or else, maybe not, but as things are
  today, it's very hard to develop a module that does
  not link to one of our's GPL'ed classes

Not sure about this one... this is what we do now with extensions so i just went with it. My initial thoughts are that any GPL compatible license would be ok...? so an extension could a different license...? Not sure, what do the license guru's think about this one?

* typo: "The more t4est coverage a community module
  the more credibility it gets." t4est -> test

Fixed.

Provided the contribution agreement and wording
for demotion of extension/core are taken care of,
assume I'll vote +1 (since I won't be around next
meeting).

Cheers
Andrea

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

4

Justin Deoliveira wrote:

Not sure about this one... this is what we do now with extensions so i just went with it. My initial thoughts are that any GPL compatible license would be ok...? so an extension could a different license...? Not sure, what do the license guru's think about this one?
  

I think we are stuck with GPL given the geoserver interfaces; you could try isolating out the GeoServer "dispatcher" system as GPL w/ classpath extension but that
would be a long term decision.

If possible I would like to add a user interface requirement to extensions; I understand that this sets a high bar for an extension but I think it is important that extensions be "product ready" to the same level we expect of geoserver modules.

Cheers,
Jody

5

If possible I would like to add a user interface requirement to extensions; I understand that this sets a high bar for an extension but I think it is important that extensions be "product ready" to the same level we expect of geoserver modules.

I disagree here. A UI is nice and often needed but there often cases where a UI is unnecessary, like data store extensions where we do fancy introspection to create the UI. With the new configuration and a java bean only philosophy for config objects i see this being more popular.

It also limits the scope of extensions imho. It limits them to things we want to manage with the user interface... Like for instance it might make sense for a certain extension to be configured via a rest interface, or some other tool for that matter.

My 2c.

-Justin

6

Justin Deoliveira wrote:

If possible I would like to add a user interface requirement to extensions; I understand that this sets a high bar for an extension but I think it is important that extensions be "product ready" to the same level we expect of geoserver modules.
    

I disagree here. A UI is nice and often needed but there often cases where a UI is unnecessary, like data store extensions where we do fancy introspection to create the UI. With the new configuration and a java bean only philosophy for config objects i see this being more popular.

It also limits the scope of extensions imho. It limits them to things we want to manage with the user interface... Like for instance it might make sense for a certain extension to be configured via a rest interface, or some other tool for that matter.
  

Maybe the requirement could be 'All configuration options added by the module must be exposed in the web interface?' I am having trouble thinking of a use case where a module that adds options would be better off without a human-friendly UI; what sorts of things did you have in mind?

-d

My 2c.

-Justin

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

7

Maybe the requirement could be 'All configuration options added by the module must be exposed in the web interface?' I am having trouble thinking of a use case where a module that adds options would be better off without a human-friendly UI; what sorts of things did you have in mind?

An example off the top of my head would be integrating geoserver with another components... say for instance we wanted to bundle up Geonetwork as a geoServer extension. (This is hypathetical yes). But it already has its own tools and methods for configuration, so i don't see much point in redoing it in the GeoServer user interface.

Anyways, I agree that a user interface is important for any extension... but not as important as keeping a low entry barrier imho. The last thing I want to tell a developer who is willing to spend time to maintain a contribution that they have to learn wicket and build a pretty user interface before we accept it.

-d

My 2c.

-Justin

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

8

Justin Deoliveira wrote:

If possible I would like to add a user interface requirement to extensions; I understand that this sets a high bar for an extension but I think it is important that extensions be "product ready" to the same level we expect of geoserver modules.

I disagree here. A UI is nice and often needed but there often cases where a UI is unnecessary, like data store extensions where we do fancy introspection to create the UI. With the new configuration and a java bean only philosophy for config objects i see this being more popular.

That is an interesting and fair insight. If there is a fancy introspection system to make the contribution show up in the user interface that is fine by me. My focus here is on providing the user community some assurances as to what they can expect when something is dubbed as a "GeoServer extension" - I would like such things to be considered as additional as functionality that is "ready made" with the same attention to user experience as the core product.

It also limits the scope of extensions imho. It limits them to things we want to manage with the user interface... Like for instance it might make sense for a certain extension to be configured via a rest interface, or some other tool for that matter.

I am not sure I am comfortable with the generalities here - it seems you have a different level of contribution in mind than me. Perhaps we can offer some additional examples?
- I am thinking of large blocks of functionality like WPS; where I expect a user interface with the ability to manage "thread pool" settings for example.
- If you are talking about bundling up some additional DataStore that would be fine as well; and I agree the existing user interface would integrate them with the over all experience (that is the result of hard work done in anticipation of new DataStores; as such it would be easier to contribute additional DataStores..).
- I can also consider a tile cache, or a user track where a directory, or local hsql database will be created and/or managed - I would expect a configuration screen to perform some common admin tasks

What kind of contributions are you thinking of here Justin? What can be managed by just a REST API? Even a REST API (for say usage metrics) may have some interaction with the security system should it not?

Jody

9

Jody asked me to look this over...

Looking at the requirements:

-"3. The module is considered "stable" by the majority of the PSC."
This might create a bunch of extra work for all PSC's. How about a sponsor PSC to commit some time to give it a proper run through rather than all PSC taking a quick glance. Perhaps after the initial 'sponsor' gives the thumbs up, other PSC's can take a closer look. This might just save everyone some time.

-UI
If a UI is provided, it needs to go through a quality review. At least to make sure the UI is up to standard.
I think a UI is necessary if the module is to be considered an extension and not a community module. If it's an extension, it should be on par with other Geoserver features.

-Is there some time requirement before a module can be promoted from a community status to an extension?
I think this would speak to stability somewhat (if it's been active and maintained for a while, it's probably more stable than something that just got created). I guess really adoption of a 'handful' of users is really the minimum time required thus far in the proposal.

Amr.

Justin Deoliveira wrote:

Hi all,

I have revamped the extensions/community module GSIP:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I have taken into account Jody's feedback, and also some of the conversation that has taken place over IRC while I was away.

Please look over again and provide any more feedback, or comment on things you don't like or are missing.

I have also moved GSIP 17 to rejected, since its now incorporated into GSIP 22.

Thanks,

-JD

--
Refractions Research
Suite 300 - 1207 Douglas St
Victoria, BC, V8W 2E7, Canada
ph: (250) 383-3022
fax:(250) 383-2140

10

Justin Deoliveira wrote:

An example off the top of my head would be integrating geoserver with another components... say for instance we wanted to bundle up Geonetwork as a geoServer extension. (This is hypathetical yes). But it already has its own tools and methods for configuration, so i don't see much point in redoing it in the GeoServer user interface.
  

Fair example; could we ask for a small user interface contribution - a simple link to the GeoServer UI showing
up once a administrator has signed in?

Anyways, I agree that a user interface is important for any extension... but not as important as keeping a low entry barrier imho. The last thing I want to tell a developer who is willing to spend time to maintain a contribution that they have to learn wicket and build a pretty user interface before we accept it.
  

I understand and respect your concern here; if this was a developer facing product like GeoTools I would be in agreement, I view GeoServer as moving out of research mode and into product mode for GeoServer 2.x series - as such I like to stick to my guns on this one. The user interface is the application; and if a customer is paying me to bring a module in as a geoserver extensions I could not honestly expect them to take me seriously if the functionality did not show up in the user interface.

Jody

11

What kind of contributions are you thinking of here Justin? What can be managed by just a REST API? Even a REST API (for say usage metrics) may have some interaction with the security system should it not?

I am thinking any kind of extension... When I think of extension I think of something ranging from a small datastore extension, to a service extension like WPS.

Anyways, yes I see your point, there is always a case for a UI. I agree with that. Its just I don't think it should be a blocker. I mean.. .if it is we can say bye bye to bundling geowebcache with GeoServer... since it has no UI.

Jody

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

12

Well since there is disagreement I guess we need to open it up to other PSC members and developers to weigh in on this issue before we can move this forward.

Jody Garnett wrote:

Justin Deoliveira wrote:

An example off the top of my head would be integrating geoserver with another components... say for instance we wanted to bundle up Geonetwork as a geoServer extension. (This is hypathetical yes). But it already has its own tools and methods for configuration, so i don't see much point in redoing it in the GeoServer user interface.
  

Fair example; could we ask for a small user interface contribution - a simple link to the GeoServer UI showing
up once a administrator has signed in?

Anyways, I agree that a user interface is important for any extension... but not as important as keeping a low entry barrier imho. The last thing I want to tell a developer who is willing to spend time to maintain a contribution that they have to learn wicket and build a pretty user interface before we accept it.
  

I understand and respect your concern here; if this was a developer facing product like GeoTools I would be in agreement, I view GeoServer as moving out of research mode and into product mode for GeoServer 2.x series - as such I like to stick to my guns on this one. The user interface is the application; and if a customer is paying me to bring a module in as a geoserver extensions I could not honestly expect them to take me seriously if the functionality did not show up in the user interface.

Jody

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

13

Hi Amr,

Thanks for the feedback, my comments are inline.

Amr A. Alam wrote:

Jody asked me to look this over...

Looking at the requirements:

-"3. The module is considered "stable" by the majority of the PSC."
This might create a bunch of extra work for all PSC's. How about a sponsor PSC to commit some time to give it a proper run through rather than all PSC taking a quick glance. Perhaps after the initial 'sponsor' gives the thumbs up, other PSC's can take a closer look. This might just save everyone some time.

Yeah I like this idea, i think it makes a lot of sense.

-UI
If a UI is provided, it needs to go through a quality review. At least to make sure the UI is up to standard.
I think a UI is necessary if the module is to be considered an extension and not a community module. If it's an extension, it should be on par with other Geoserver features.

See the rest of this thread for my thoughts on this ;).

-Is there some time requirement before a module can be promoted from a community status to an extension?

I don't see a huge reason for it, no. I mean, if the code is there and is quality enough and meets all the requirements I see now reason why it should wait.

I think this would speak to stability somewhat (if it's been active and maintained for a while, it's probably more stable than something that just got created). I guess really adoption of a 'handful' of users is really the minimum time required thus far in the proposal.

Amr.

Justin Deoliveira wrote:

Hi all,

I have revamped the extensions/community module GSIP:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I have taken into account Jody's feedback, and also some of the conversation that has taken place over IRC while I was away.

Please look over again and provide any more feedback, or comment on things you don't like or are missing.

I have also moved GSIP 17 to rejected, since its now incorporated into GSIP 22.

Thanks,

-JD

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

14

Justin Deoliveira wrote:

Anyways, yes I see your point, there is always a case for a UI. I agree with that. Its just I don't think it should be a blocker. I mean.. .if it is we can say bye bye to bundling geowebcache with GeoServer... since it has no UI.

Interesting; GeoWebCache must have some kind of configuration?
- A directory it writes files into?
- Tile size?
- does it have some log settings we can change
- does it have anything?

Let me try for a real small minimum; can we have a page showing the currently loaded "extensions" and if they have been loaded correctly?
I would like to visually communicate what is going on to the user; for community modules it is not a big deal - but for an extension I want something to change somewhere at least acknowledging the existence of the extension.

Jody

15

Jody Garnett wrote:

Justin Deoliveira wrote:

Anyways, yes I see your point, there is always a case for a UI. I agree with that. Its just I don't think it should be a blocker. I mean.. .if it is we can say bye bye to bundling geowebcache with GeoServer... since it has no UI.

Interesting; GeoWebCache must have some kind of configuration?
- A directory it writes files into?
- Tile size?
- does it have some log settings we can change
- does it have anything?

It has its own configuration files, but i am actually not sure if they are read when its bundled with GeoServer, i think it auto-configures itself from a WMS capabilities doc.

Let me try for a real small minimum; can we have a page showing the currently loaded "extensions" and if they have been loaded correctly?
I would like to visually communicate what is going on to the user; for community modules it is not a big deal - but for an extension I want something to change somewhere at least acknowledging the existence of the extension.

Again a good idea... but not easy to do. This isn't osgi, we don't have a true plug-in system with a class representing a plug-in or extension that we can just lookup.

Instead of trying to add all these requirements up-front and make the process "heavyweight" from the start can we approach these as "todo's". We have a good process in place that will get us off the ground. Everyone speculating about stuff that we "will need" does not seem all that useful at this point. I mean... these are really good idea's, but i would prefer that we come back to them when they actually become an issue. For instance if we get a bunch of extensions and cant tell what he heck is going on, whats loaded and what's not, then i say we come back and re-evaulate the process.

Jody

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org

16

Currently:
It's not really a geoserver extension at this point, it's more like a separate servlet that uses the same Spring context to load. It doesn't change GeoServer's behavior, much less present a configuration page.

The only configuration variable that most people have to set is GEOSERVER_DATA_DIR. If GeoServer is not accessible through http://localhost:8080/geoserver you'll also have to set GEOSERVER_WMS_URL, but that's pretty much all you can do for the "plugin" version. Both of these values are set in web.xml or as environment variables.

See http://geoserver.org/display/GEOSDOC/GeoWebCache

In the near future:
For the next two weeks one of our recently hired developers will try to build a UI for it using OpenLayers and ExtJS. (This combo is chosen because Tim Schaub has already built applications with it that come close to doing what I think we want). It will go on top of the RESTful interface that Marius Suta has been working on over the summer (GSOC). I'm currently going through those changes and testing.

We also want to have GWC listen for GS configuration changes (read-only). So when we add that I guess we can make a wicket page that outputs basic information about the GWC plugin and a link to the JavaScript UI. I don't think making a complete UI in Wicket is realistic.

-Arne

Justin Deoliveira wrote:

Jody Garnett wrote:
  

Justin Deoliveira wrote:
    

Anyways, yes I see your point, there is always a case for a UI. I agree with that. Its just I don't think it should be a blocker. I mean.. .if it is we can say bye bye to bundling geowebcache with GeoServer... since it has no UI.
      

Interesting; GeoWebCache must have some kind of configuration?
- A directory it writes files into?
- Tile size?
- does it have some log settings we can change
- does it have anything?
    

It has its own configuration files, but i am actually not sure if they are read when its bundled with GeoServer, i think it auto-configures itself from a WMS capabilities doc.
  

Let me try for a real small minimum; can we have a page showing the currently loaded "extensions" and if they have been loaded correctly?
I would like to visually communicate what is going on to the user; for community modules it is not a big deal - but for an extension I want something to change somewhere at least acknowledging the existence of the extension.
    

Again a good idea... but not easy to do. This isn't osgi, we don't have a true plug-in system with a class representing a plug-in or extension that we can just lookup.

Instead of trying to add all these requirements up-front and make the process "heavyweight" from the start can we approach these as "todo's". We have a good process in place that will get us off the ground. Everyone speculating about stuff that we "will need" does not seem all that useful at this point. I mean... these are really good idea's, but i would prefer that we come back to them when they actually become an issue. For instance if we get a bunch of extensions and cant tell what he heck is going on, whats loaded and what's not, then i say we come back and re-evaulate the process.
  

Jody

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
    

17

Thanks Arne; the background is very useful. I actually should be joining your mailing list next week for a separate project I am working on.

Two responses:
- The basic wicket page sounds okay - it meets my requirement for "showing up" in the user interface
- What you describe is an interesting set up - it sounds like you have no actual dependencies on GeoServer code ... indeed the same functionality could be deployed as two separate WARs can it not?

Reading about your plans for the RESTful interfaces; what are you actually trying to access?
Jody

Arne Kepp wrote:

Currently:
It's not really a geoserver extension at this point, it's more like a separate servlet that uses the same Spring context to load. It doesn't change GeoServer's behavior, much less present a configuration page.

The only configuration variable that most people have to set is GEOSERVER_DATA_DIR. If GeoServer is not accessible through http://localhost:8080/geoserver you'll also have to set GEOSERVER_WMS_URL, but that's pretty much all you can do for the "plugin" version. Both of these values are set in web.xml or as environment variables.

See http://geoserver.org/display/GEOSDOC/GeoWebCache

In the near future:
For the next two weeks one of our recently hired developers will try to build a UI for it using OpenLayers and ExtJS. (This combo is chosen because Tim Schaub has already built applications with it that come close to doing what I think we want). It will go on top of the RESTful interface that Marius Suta has been working on over the summer (GSOC). I'm currently going through those changes and testing.

We also want to have GWC listen for GS configuration changes (read-only). So when we add that I guess we can make a wicket page that outputs basic information about the GWC plugin and a link to the JavaScript UI. I don't think making a complete UI in Wicket is realistic.

-Arne

Justin Deoliveira wrote:

Jody Garnett wrote:

Justin Deoliveira wrote:
   

Anyways, yes I see your point, there is always a case for a UI. I agree with that. Its just I don't think it should be a blocker. I mean.. .if it is we can say bye bye to bundling geowebcache with GeoServer... since it has no UI.
      

Interesting; GeoWebCache must have some kind of configuration?
- A directory it writes files into?
- Tile size?
- does it have some log settings we can change
- does it have anything?
    

It has its own configuration files, but i am actually not sure if they are read when its bundled with GeoServer, i think it auto-configures itself from a WMS capabilities doc.

Let me try for a real small minimum; can we have a page showing the currently loaded "extensions" and if they have been loaded correctly?
I would like to visually communicate what is going on to the user; for community modules it is not a big deal - but for an extension I want something to change somewhere at least acknowledging the existence of the extension.
    

Again a good idea... but not easy to do. This isn't osgi, we don't have a true plug-in system with a class representing a plug-in or extension that we can just lookup.

Instead of trying to add all these requirements up-front and make the process "heavyweight" from the start can we approach these as "todo's". We have a good process in place that will get us off the ground. Everyone speculating about stuff that we "will need" does not seem all that useful at this point. I mean... these are really good idea's, but i would prefer that we come back to them when they actually become an issue. For instance if we get a bunch of extensions and cant tell what he heck is going on, whats loaded and what's not, then i say we come back and re-evaulate the process.

18

Jody Garnett wrote:

Thanks Arne; the background is very useful. I actually should be joining your mailing list next week for a separate project I am working on.

Two responses:
- The basic wicket page sounds okay - it meets my requirement for "showing up" in the user interface
- What you describe is an interesting set up - it sounds like you have no actual dependencies on GeoServer code ... indeed the same functionality could be deployed as two separate WARs can it not?

Yes, it can (and there are downloads available). It requires a bit more configuration and increases the memory footprint and disk usage because it (surprise) has a lot of the same dependencies as GeoServer.

We would like to listen for GS configuration changes though, and that would at first only be available to the plugin version.

Reading about your plans for the RESTful interfaces; what are you actually trying to access?

Only configuration (what layers are available, what output formats and projections each of them are configured to support) and seed requests (multithreaded and with queue, inspired by Hudson).

-Arne

<snip>

19

Thanks Justin; I am going to be away next week and thus miss the meeting.
This discussion has gone very well - and would like to offer my +1 vote at this time. It looks like everyone has considered and understood my request to make contributions available in the user interface - I am able to accept that it is too strong a requirement.
Jody

Justin Deoliveira wrote:

Hi all,

I have revamped the extensions/community module GSIP:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I have taken into account Jody's feedback, and also some of the conversation that has taken place over IRC while I was away.

Please look over again and provide any more feedback, or comment on things you don't like or are missing.

I have also moved GSIP 17 to rejected, since its now incorporated into GSIP 22.

Thanks,

-JD

20

Great, thanks Jody, your feedback as always is great. While I do think the UI requirement is a bit premature, its definitely on the list of things to look out for after we assert this process as successful. I am going to add a section to the proposal and resulting process doc called "Future Amendments" to track things like this that we may want to add to the process later.

-Justin

Jody Garnett wrote:

Thanks Justin; I am going to be away next week and thus miss the meeting.
This discussion has gone very well - and would like to offer my +1 vote at this time. It looks like everyone has considered and understood my request to make contributions available in the user interface - I am able to accept that it is too strong a requirement.
Jody

Justin Deoliveira wrote:

Hi all,

I have revamped the extensions/community module GSIP:

http://geoserver.org/display/GEOS/GSIP+22+-+Community+Modules

I have taken into account Jody's feedback, and also some of the conversation that has taken place over IRC while I was away.

Please look over again and provide any more feedback, or comment on things you don't like or are missing.

I have also moved GSIP 17 to rejected, since its now incorporated into GSIP 22.

Thanks,

-JD

--
Justin Deoliveira
Software Engineer, OpenGeo
http://opengeo.org