Thanks for the wonderful feedback:
Your questions point towards the kind of long term planning that we are lacking at the moment. What we are on the verge of developing (skating around as it were) is a plug-in system for OGCish services.
The configuration design we are working on this week is really just focused on the existing XML config files. I am afraid I don't have time for more then that at the moment.
There are a couple of screens in the workflow diagram - that have not been fleshed out. When you first "log-in" there is a screen for GeoServer management". This screen is never sketched out - it does not reflect a configuration file.
I had intended to place:
- Status Information
- Access to Log files (or at least the tail )
- A big button to kill all outstanding FeatureLocks 
But really the individual WFS/WMS should provide a Tile based user interface which the GeoServer framework can include on this page. Similarly the WFS/WMS should manage their own configuration file and provide there own user interface for setting it up.
The password/security issues have also been discussed - and there is a real need. (their is GeoInnovations money in Canada chasing around just such a solution - I am afraid the deadline has passed though). Where things get complicated is passing credentials along a chain of proxy WFS or a WMS backed by a WFS.
One good thing is - FeatureType ("Layer" in your email) configuration is centeralized. But the FeatureTypes are enabled separetly for the WFS and WMS.
Now that I think about it - the Enabled process for the WMS and the association of FeatureType to Style information should both be done on the WMS screen. The idea is to separate out defining data in the Catalog component from the serving of Data in the WMS or WFS components.
The STRUTS framework does provide http calls for this configuration process. There is example documentation out there on how to do this. However - STRUTS is Data Transfer Object based (using Beans for message passing) and the usual way to build a SWING app on top of struts is to use RMI with the DTO directly. (Look ma - no XML).
My mail server has been blacklisted and sf is not accepting the mail... hope
you'll receive it anyway...---------- Forwarded Message ----------
Subject: Some thought about Geoserver (and its configuration)
Date: Tuesday 30 December 2003 12:32
From: Andrea Aime <andrea.aime@anonymised.com>
To: geoserver-devel@lists.sourceforge.netFirst of all, it seems that Geoserver is going to become a container for
various GIS oriented services, which is good. It would be nice to have the
ability to:
* start/stop every service interactively (by using the web configuration
interface) * avoid unneeded classloading if a service is marked as non
active (that is, don't set up the service at all, and not get it up and make
it refuse every call) * a service can be conceived as a set of calls that
perform some action and may produce some results. It would be nice to have
some kind of user based authorization scheme that entitles the use of
certains calls to certain users (that is, and ACL for each action of each
service). The authorization framework should be a set of interfaces and
factories so that geoserver can be plugged into a bigger system using an
existing authorization schema (maybe the JAAS specification and library can
be useful for this, but I'm not sure).
* a net based mask can be useful too. For example, allow access to a certain
service only from a certain subnet. The Posgres pg_hba.conf file for example
allows to setup a special authentication mechanism for specific network
masks (for example, local users, trust, local net, ident, internet users,
mda5 based passwords and the like). Also SAMBA allows this kind of
authorization scheme.
* some services may need to travel over HTTPS. How can we configure this? For
example, let's say I have sentitive data, they may travel in cleartext GML
on the local network, but I want them to be served over https for internet
users and have people provide authentication before allowing access.It would also be nice to have the configuration services available as http
calls to make it possible to build a workstation administration program
which is Swing based (something like a central app that allow to load up
data on the server, configure it, create web maps, create validation
criterias and the like). I know it's more work, but at least properly factor
out the web configuration interface in order to make building a
configuration servlet easy when needed would be nice.Some other thougts:
* layer configuration is centralized, but I think it would be better to make
it service based. For example, what if I have a layer that I want to serve
using the WMS but I don't want to make it available for the WFS service?
* model classes really need to be names as xxxModel? It seems a bit ugly to
me (just personal taste).Hope this helps
Best regards
Andrea Aime-------------------------------------------------------