I have some thinking to do; I think we have a shared understanding of the requirements here.
This is a flexible topic where we will get a different results based on what trade offs we are aiming for. To that end could I ask what your priorities (and Justin?) are:
- Jody - clear API for developers
- Jesse - listed on a wiki page (remember error reporting as a concern)
- Andrea - ?
- Justin - ?
After we set priorities we will be in a better situation to choose between alternatives.
I often split this idea into two:
a) Catalog - provides the ability to search for information
b) LocalCatalog - takes responsibility for hold the data references
Hem... can you elaborate a bit more on this? This would be a split
between one that knows how to search, and another that knows how to cache, so the second would wrap the first?
This Catalog interface lets client code look up references to services. That is it does a search (based on the description of the resource which includes its bounds); and returns a list of references that match. Client code may "connect" to these references; which will involve them being added to the "LocalCatalog".
uDig has implementations of Catalog for a GeoConnection discovery protal, and a quick web service paul ramsey provided.
This just "finds" spatial data.
The LocalCatalog "manages" connections to data; yes it still implements the catalog interface (so you can find information that is already known to your application). The LocalCatalog "references" will lazily connect to DataStores and hold references to them so they can be shared between application modules.
The difference between the two is an "add( IService )" method where you can add additional entries to the local catalog.
One thing we have missed a couple times is the security / authentication / authorization concern. I would like to ensure we keep this in mind when we work through this "info" layer.
I would not put this one in the Catalog classes, but following the lines
stated above, we could have a third wrapper that knows how to apply security policies and hide/show things (a SecurityEnabledCatalog wrapper class). This would shape catalog API as something similar to the java
i/o API.
I don't mind if it is a wrapper or a stratagy object that the catalog consults for security concerns. I had planed out the stratagy object approach in uDig just so I could reduce the number of classes users are forced to notice. The stratagy object was also going to take care of persisting the security credentials serpartly from the "configuration" of the catalog.
Oh, we probably may want a "composite" or "chained" catalog
as well, so that people can provide their own replacement or extra
search level catalogs (that would be a way to integrate with external
providers such as GeoNetwork, for example).
See above; we have this idea in uDig already. What we do with one of these "remote" references is answer the questions we can just using the information returned by the search results (name, title, bounds, description etc...). But when it comes time to actually connect (FeatureType, legend graphics etc...) we add to the local catalog, connect and delegate.
3. Another collection of java beans that are used to configure services. We have these also, WMS, WFS, GeoServer, etc...
I would like to "tone down" this requirement to *only* describe the service; and make sure we have "per service" information available against the actual data entries as part of 2. That is a resource should be responsible for knowing it's FeatureType (ie schema), applicable NamedStyles for that schema, and the default NamedStyle. These are properties of the data entry, irrespective of GeoServer having the WMS service enabled or not.
I'm not sure of it... a default NamedStyle is something we need only for
WMS, WFS and WCS are not interested in it, so I would not have it around
at all if we ship a configuration without WMS around.
You are correct - the information we store "per reference" does depend on what modules are available. The benifit of using the catalog for this is that all the information associated with a resource is in one spot. we have the chance to follow associations (so geoserver is usable with large number of datasets with less configuration steps etc...). As an example the keywords are used by WFS, WMS and WCS. The named style(s) are actually defined against the FeatureType (not the resource layer), so lookup by resource does not imply configuration by resource (a separate module can take responsibility for associating resource to style, client code such as WMS need not know or care how the style was produced).
A couple of points:
- security / rolls - mentioned above
- lazy (we do not want to connect to everything, only what is needed). This may involve caching some information for answer GetCapabilities requests (hense 1 is often confused with 2 above). In uDig this feature request takes the form of caching schema information or GetCapabilities documents between runs.
- associations (ie FeatureType, Schema, Metadata)
Associations are indeed a hard nut to crack... how do we keep things consistent (I mean, a foreign key type of consistency).
Well the "worst" way (that still works); is to ask client code to perform additional lookups in the catalog. Defining more API for each kind of information. I enjoyed hiding this concern myself, but I think you found the result too opaque when reduced to a single "resolve" method.
Cheers,
Jody
