Subject: Exported From Confluence
Content-Type: text/html; charset=UTF-8
The existing catalog interface has a description, the following is just =
- Catalog: facility to locate (or search for) geospatial resources. Th=
is is just an interface and is often implemented against a remote web servi=
- LocalCatalog: manages "live" resources, supports the same =
"search" functionality as Catalog, but also takes responsibility =
for storing the actual "connections". The LocalCatalog will manag=
e your DataStores and GridCoverages for you.
If we were forced to drop the word catalog we would be left with:
- ResourceLocator - search for resources
- ResourceManager - manage resources, and any connections or data asso=
ciated with them.
(I would prefer to stick with Catalog and LocalCatalog)
The GeoTools Catalog interfaces has the following history:
- GeoServer Data module defined 2003
- GeoServer Data module "lookup methods" isolated as GeoTool=
s Registry API in 2003, with the addition of "cross datastore" op=
- GeoTools Registry API used to inform uDig Catalog in 2004
- GeoTools catalog derrived from uDig 1.1 catalog in 2006
The wheel has now turned full circle and we are looking to share a commo=
n API for this idea between both GeoServer and uDig. The fact that an imple=
mentation will also remove the boiler plate datastore managmenent code from=
our examples (and developer community) is a big plus.
The following notes have been collected from email, we will try and redu=
ce them to either acceptance tests or guidelines when choosing between alte=
- Service and GeoResource is lazy loading.=C2=A0 IE obtaining a refere=
nce to them will not block.
- There must be a method to obtain error and warning messages.=C2=A0 S=
uch as misconfigurations, sub-optimal configurations or broken connections/=
- There must be events when the connection to resources change and whe=
n cached values change.=C2=A0 The events must provide enough information to=
accurately determine what has changed
- The burden of a contributor must be minimalized.=C2=A0 IE there shou=
ld not be an unreasonable number of classes that they must implement.
- There must be a way to handle session properties.=C2=A0 As a use-cas=
e consider what happens when a client is operating on a FeatureStore within=
a transaction.=C2=A0 There must be a way to query the GeoResource for the =
bounds and have it return the correct bounds considering the transaction.=
- Clear API for developers, I am okay with some complexity for impleme=
nters as long as their is a strong usability benefit.
- Preserve the resource to Style association as a user story
- Clean up the current mess that is our config/catalog api
- Have a way for people to plug in their special catalog implementatio=
- Allow for clustering (aka, store config in a central location, be it=
a database, or a separate Geoserver publishing its configuration to "=
slave" Geoservers). Please note I've written allow, I mean th=
at the API we choose should not go against a db based API, not that we wil=
l make one
- Have Geoserver scale on the thousands of feature types/coverages.
- What is the benefit to users of GeoServer?
- I want the Ingestion Engine save the new configuration somewhere (Di=
sk or DB) independently from GeoServer, and have the GeoServer catalog alwa=
- Don't load all the resources every time into memory, but ask just fo=
r the resoucre I need.
- Cache the resources in order to avoid to request them to the service=