The real issue is that FeatureTypes are defined by the contract between the service and the user, not the contract between the service and the persistence layer designer.
In other words, the requirements for interoperability drive the application schema ( FeatureTypes ), and the service _implements_ a FeatureType. Thus, the configuration should follow this pattern, even if a "temporary Feature Type" is auto-created from the persistence layer, logically the config should keep it separate as if it had been created by an external specification process.
Well, that's just a matter or having a layer of mapping, such as the
complex data store, properly configured and sitting on top of
the basic data stores.
True, but this also suggests where to put the user friendliness..
Stores and FeatureTypes are mixed up at the moment. Conceptually a store manages a connection _and_ a persistent object, from which multiple FeatureTypes may be mapped to the underlying persistence layer. I think there is scope to refactor this better.
Sorry, the persistent object is?
shapefile, db table etc
A single XML document is a bad idea IMHO, although one could be autogenerated from linked fragments if required to see the entire configuration. Tools could deal with the reusable fragments as easily, or more easily, than a monolithic document whose content and structure changes with every functionality change,
Which tools? I'm quite XML ignorant, but our current approach leads
to inconsistency.
Ahh - I agree that the monolithic nature of the current approach is problematic. But moving to a monolithic config document is maybe the wrong way to fix this.
Plus, XML is used just for persistence, what geoserver
deals with is a big in memory model, and each time it stores it, it's
stored in its completeness,
so, if part of it was imported, this model is a problem isnt it? Maybe this is the bit to think about, can configurations be loaded and unloaded ina modular fashion. This in turn buys benefits for configuration testing at the very least.
we do not change only a few XML files,
so we are really treating the configuration as monolithic, having
split files does not change anything, just allows for more confusion.
A monolithic document is good as long as we keep the configuration
model completely in memory, and can be generated fast enough with
persistence libraries such as XStream.
OK - but you cant hand off to individual models the responsibility to marshal and unmarshal configurations easily then.
I'd imagine a few config wizards to fix the problem:
Datastore connection manager (smart enough to handle pooling etc)
FeatureType install (from external catalog, or build your own wizard from a persistent object)
Service Profile - use provided machine readable service profile to set up service metadata and supported SRS defaults etc. (May also install a set of FeatureTypes - eg Transport server has Road, Junction, Route, Rail, etc)
Data object to FeatureType mapping wizard.
If you are dealing with a model big enough that in memory handling
does not cut it XML is bad anyways, a dbms should be used instead to have consistency assurances and decent performance (even an in-process
one like h2 or hypersonic, but using cached tables, not in-memory ones).
Its not the in-memory size in question -its whether you can cope with all the interdependencies on modules encapsualted within a single object.
A wizard type approach that joins the artefacts into a loadable subset of configuration elements, and enforces the "foreign key" relationships would be worthwhile, because its hard to configure at the moment, primalrily because all the sources of errors are swallowed. You are right it needs improvement!
Cheers
Andrea
