I really like gabriel's re-organization plan - I'd like to hear what
jody says about it, but it looks like gabriel's and jody's ideas are
pretty much hand-in-hand.
Does this mean that the Geoserver will look like this:
http://localhost:8080/geoserver/config -- server level configuration
http://localhost:8080/geoserver/data -- all the data services
http://localhost:8080/geoserver/data/config -- all the data
configuration
For a service plugin, in this case "wms":
http://localhost:8080/geoserver/wms -- all wms service & support in here
.../geoserver/wms/config -- wms configuration ui
.../geoserver/wms -- send your getCapabilities here
Where wms is basically a .jar that we stuck in geoserver. Geoserver
noticed the jar and the jar said "my service is 'wms', I have a
configuration package 'wms/config'". Geoserver tells the package where
its .xml configuration file(s) are.)
It seems that "data" is basically behaving like a geotools-datastore
catalog. I think we'll need to put some thought into this so its easy
for plugins to figure out what data is available, etc..
I'd also like to see if it were possible to make it easy to chain
services (or service components) together.
What kind of services do we want available for other to build on top of?
WFS and WMS because we already have them, but coordinate transform and
rendering services would also be nice so people can start re-using
things in a well-known manner.
-----
Here's an example of a little web application I wanted to do. Lets
assume the developer doesnt really know too much about STRUTs,
geoserver, or geotools, so they dont want to do anything "deep" - they
want it fast and easy.
For the FeatureType configuration screen, the user has to enter in the
bounding box (in lat/long) for their dataset. Jody and I recently
changed the behavior of the "generate bounding box" button so that it
was co-ordinate system aware - it finds the bounding box of your data
then transforms it to lat/long.
This can be a bit tricky - its easy to make a mistake and not notice
when looking at the lat/long numbers.
I wanted to have a little button that would pop-up a world map showing
your bounding box. So, if you expect your bounding box to be over los
angles, and its over top of Cairo, you know you've done something
wrong!
How *exactly* do we want people to actually set this kind of service up?
Is this the kind of thing that we want in geoserver? Is geoserver a
generic Geographic-based web service framework?
Should they even be considering using geoserver to "host" this type of
application? Or should they just "roll their own" in some other web
application package?
Lets assume they want to put it in geoserver so they can have all the
service in "one spot." How should they go about doing this? Whats the
best way for them to plug in?
Now, there are thousands of ways of setting this up. Lets take the
absolute easiest way:
1. setup a WMS for the world map (either local or just use someone
else's)
2. make a new service that's really simple - takes in an input bounding
box and returns an image.
So, they make a configuration that looks like this (with an appropriate
xml schema for validation):
<worldBoundingBoxConfig>
<boxColour>
RED
</boxColour>
<boxWidth>
2
</boxWidth>
<zoomoutPercent>
15
</zoomoutPercent>
<worldMapService>
...URL...
</worldMapService>
</worldBoundingBoxConfig>
Our new webservice communicates with the geoserver configuration,
allowing it to request and put a configuration XML document. Geoserver
takes care of persisting (and perhaps versioning) and validating the
document and the webservice provides a GUI for modifying it.
This is a really simple service so lets say they have a single .jsp page
for configuration. (WHEW! dont have to know anything about STRUTs)
Geoserver handles incomming request and routes the appropriate ones to
our webservice. Again, our service is really simple, maybe its a little
servlet or even a single .jsp page. It:
1. gets its configuration
2. looks at the incomming request and gets the bounding box.
3. creates a getMap request for the appropriate bounding box
** probably use a geotools package to fill out a GetMap request
4. send off the getmap request
** perhaps with geotools help
5. get back the image
6. paint the bounding box rectangle on the image
** a rendering service would be great here!
7. returns the resulting image.
How do you envision people actually writing their services? What
"tools" are we going to give to them? Whats our goals?
----------------------------
I really like the configuration application - its easy to use and seems
to work well.
I'm just been looking through the STRUTs stuff - its quite difficult to
figure out. I dont really know STRUTs so that could be why I'm having
problems.
STRUTs is supposed to make your application easier to maintain, but...
For example, the only comment in editor.jsp is:
<%
//This file contains some ugly JSP code.
//Be wary, ye who brave the dragon's lair.
%>
And editor.jsp is the most complex page in the whole system! It
difficult to know what .jsps are rendering any particular page, and
find what bean (and action) is associated with a .jsp. There's a lot
of indirection between the tiles, .jsps, struts-config, actions, and
forwards.
There also appears to be orphened pages, actions, and properies.
Hopefully all this will become much more obvious when I learn a bit more
about STRUTs and the actual application.
There's probably a bunch of hand-drawn pictures somewhere of each page
that would say what tile set makes it, what the components of the tile
are, how it interacts with the actions (and how they interact with the
underlying configuration), what information is available in the bean
given to the .jsps, and where all the forwards go. Most of this
information is available from STRUTs, but its difficult to find
after-the-fact.
STRUTs is supposed to make it easy to re-factor, but I think you really
really really have to understand whats there before you could even
attempt a refactoring.
But, as I said, its a good application and I dont really know STRUTs.
I'm hoping I'll just wake up one day and say "its all obvious, how
could I have not understood it!".
-------------
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
