David Blasby wrote:
>>... - it would let the WCS work as a module rather then a branch etc...
Okay, everyone is selling whats happening in 1.4 to allow this, but no one's really explained how its supposed to work. I've asked many times, but I've gotten no answers.
Right that is because nobody knows *exactly yet* - however here is the trick. When making a system like this I tend to:
- define an api as a conversation starter
- have someone start implementing against the api
- have someone else start writing the framework around the api
As both side learn what is needed, the API will be changed. If those implementing against the API find they are doing too much boiler plate code they will push back and the framework will need to do more. If they are running into assumptions the framework made incorrectly they will pull back some functionality and so on..
However that is how I like to set up a good system. I think you were asking for exact technical details...
Andrea was going to explain some of the details during Monday's meeting. Here is my rough take, remember I was sick when i was trying to listen to him so this is really only an overview. I cannot remember method names for example.
1. Maven 2 modules, so that you can specify what you want your WAR to depend on (aka an easy way to set up a geoserver configuration for release).
2. Replacing the struts xml file that specifies the geoserver modules (and how to wire them up), with a much more dynamic spring xml file for the same thing. The struts one is explicit (start data, then wfs, then wms, then config), the spring one can be split into chunks (one per each maven module) and can sort things out based on what "modules" are on the WARs classpath
3. FactorySPI to figure out what is on the classpath (aka what geoserver does now) involves having little text files in the manifest, or look into some Spring thing that apparently is more clean (you can search for classes implementing an interface) and does not involve a text file.
If the WCS branch was completely independent of the rest of Geoserver (ie. just another servlet), then I can see what you're saying working. In fact, if that really were the case, then they could just publish the WCS stuff as a separate servlet and not need to change [the current] geoserver much - if at all.
My understand is that it also hooks into the Request / Response (remember that any request to the "base url" + SERVICE=WCS should be dispatched to the WCS module. Now our request Request / Reponse system is already set up for extention, we would need to have it check the classpath for additional "handlers" inorder to dynamically intergrate additional services like WCS.
But, my understanding of the WCS branch is that its not independent (perhaps someone there can comment because I havent poked much around in what they're doing). It's modified the WMS so you can get raster-in-WMS. I assume there's some type of coverage server (unless they've just extended the wms). There's config system changes (including the GUI) and data changes. I assume they've added a few other things here and there.
I can see how the new spring system might help with adding in a new servlet, but what about the rest? These are the more interesting (and more important) tasks. Is the statement at the start of this message just hyper-marketing or is there some type of spring magic that makes all these other things trivial?
No magic, just build on the basics outlined above. But now lets think about what we can do with those basics ....
Just like the Request/Response system was set up to allow for expansion each module should advertise
how its "config" should be done. So right now we have a JSP that manually lists each "modules" config information, WFS, WMS and Data. Processing that off the classpath would smoothly add WCS into the mix.
In terms of the code dependence of WCS to WMS that is just handled by maven, does not make any difference to the runtime.
Now in terms of "hyper-marketing"? Nothing in spring will make the above problems go away, the only advantage we have is that our code is already modular and that we understand the codebase and know some easy places where we can already allow extension.
Spring may be good, and offer us some "obvious" ways to handle things like security, but for right now I a focused on a much smaller problem - cashing in on the already good design we have in GeoServer.
Phrased another way: Justin pointed out that there is a lot of work to be done to take full advantage of Spring. I do not deny that, I only want to point out that I do not want to take full advantage right now. Even the a small advantage, for a small change, is worthwhile.
ps. I'm looking forward to the wcs branch since there's a bunch of raster data that I'd like to publish.
We all are, uDig has a couple escape options but geotools based raster support would be good.
ps. I am a bit concerned that WCS is stuck behind the FM branch and we have not all lined up the resources needed to complete these things. Any chance we can scare up Justin some more help? I know I am volunteering, but perhaps someone on the WCS side of things would be interested in at least trying out opperations (to ensure they meet the WCS needs).
Jody
An recent experience on the FM should also provide warning of the dangers involved.
An recent experience on the FM should also provide