Rob, I'm answering here since confluence is not really designed for
threaded discussion and page evolution may make comment outdated and/or
irrelevant (which may confuse readers imho).
> OK - some other perspectives, which IMHO would lead to a reappraisal
> of the requirements along the lines of Chris's comments.
> In general, deployment of _interoperable_ services requires
> conformance to a particular _profile_ of the underlying base
> standard. for example, a bunch of counties might deploy schools data,
> transport condition updates.
> Motherhood statements, but with significant implications:
> Each content offering (Feature Type, Layer etc) will need to conform
> to at least two profiles: the jurisdictional/enterprise view (all
> our services have the following metadata etc) and the content related
> standards (you must be able to perform these queries against this
> data standard).
Rob, a couple of paragraphs and I've already lost you, LOL! :-)
Configuration and profiles are related, yet different in my opinion.
Say multiple conties deploy schools data.
Most probably (at least in Italy, don't know about USA) each county
already has that data, and it's managed in different format that
does not match the profile. They won't change the format, because they
have existing applications running on top of it.
So, to satisfy the public profile they probably:
a) configure their datastore in Geoserver as they are
b) fiddle with complex data store configurations so to build the
public profile out of their actual data structures
Geoserver configuration should store a) and b), not the public profile?
The public profile is what you get when you do a GetCapabilities
request, that is, not the actual Geoserver configuration, but
the published service configuration, something that's computed,
not stored, and not even used by Geoserver internally?
> Thus, R1 seems to be not so much a requirement as an implementation
> strategy, and not one that fits the real set of requirements.
> Now, the ability to maintain ID refs and provide meaningful reports
> on errors, regardless of single or multiple files seems to be a
> common concern.
> I'd suggest replacing R1 with:
> 1a) Add ability to check for logical inconsistencies between
> configuration components
> 1b) Propagate errors and warnings to system manager (via UI, URL
> accessible config log or email in the future) in such a way that the
> underlying cause can be readily identified
> 1c) Allow importation of external XML resources (e.g. schemas, but
> also feature type definitions, service profiles) into a local cache,
> with ability to refresh from external source, saving old versions.
> 1d) Allow plugin services, including configuration and metadata
Indeed you're right, I've tried to amend the document to incorporate
1a), 1b) and 1d).
1c), I'm not sure I understand. I have my own data which does not match
the public profile. I do import the public profile, and then have
mapping tools that make me go from actual data storage to the
agreed upon data exchange formats. What configuration should store
the mappings, the public profile by itself may be stored too
as a reference. Is that what you mean?
> The way forward would be to revisit this issue with a "separation of
> concerns" perspective. IMHO, we havent really got together all the
> usage patterns, so we're reacting to the problems inthe current
> system rather than designing for the future. If so, then its better
> to recognise its a pure band-aid and avoid overcapitalising.
We're working on different time scales. I know current UI and config
is a waste of time and want one that allows me to easily add the new
services we're planning to support in the next couple of months.
It seems to me you're planning on the 6month-1year timescale afaik.
We're also targeting different needs: I do care about our current
users and their typical needs.
The needs you're trying to address are more complex, less common.
> It may be possible to provide a navigator/editor that traverses the
> links between plugged-in object configurations (ie. a single virtual
> XML file that doesnt need to be manually constructed from many
> fragments). I wouldnt like to see such an investment without more
> analysis of the actual requirements.
Such an investment? The simplistic Xstream based solution I was
proposing would have taken less than a week to implement, the one we're
discussing now will take 1/2 months in discussion, design and
> I'd go back to basics and
> describe the Use Cases for configuration changes. The Use Case
> described is a very specialised one - a developer adding a piece of
> For every developer, there will be many configurators, and for every
> deployment, many end-users. I beleive if we had sharable
> configurations, the orders-of-magnitude would look like this:
Sharable configurations... I don't see their applications besides a
cluster. A sharable configuration assumes you have the same kind
of databases, same data structures and the like.
My experience tells me at least here in Italy everybody does its
own, so you may well have people agree on a profile, but each
will do its own when it comes to data management, so configuration
(set of datastore parameters, feature type configurations, mappings
from storage types to published ones) is simply different for each
> developer -> data type configurator -> deployer -> user
> And the config system is pretty bad for the deployer IMHO.
I agree the UI makes you jump thru many useless hoops.
But it's the UI, not the config system itself.