Hi Ben; if you have a checkout of 1.7 I would not mind a second eye checking my last couple commits.
As for the geoserver catalog / workspace ideas - please view it as a documentation challenge. This is an area where you can help document what is there now; and I do not think anyone intends for the workspace = namespace relationship to continue. If you can plan out what the correct relationship would be it would really help when we consider situations like this Repository interfaces. We need build against what we have; while planning for the future. Now I am really interested in the "lookup" facilities you have provided for your module - can we start a separate email thread. Comparing what you have to this real minimal that Christian and I worked out? I hope to see two ways of looking things up (one "logical" workspace/datastore/name and one "domain" based - profile/applicationSchema/featureType (where applicationSchema would have a namespace). Cheers, Jody On Tue, May 19, 2009 at 2:08 PM, Ben Caradoc-Davies <[email protected]> wrote: > app-schema needs a better way of registering DataAccess instances, which > must collaborate with each other to perform feature chaining. At the moment, > we have an AppSchemaDataAccessRegistry. When we understand the Repository > API, we might use it. > > Because feature chaining *requires* collaboration between DataAccess > instances in different namespaces, and because GeoServer *requires* the > workspace name to be equal to the namespace prefix (GEOS-3042), > cross-workspace communication is *required* for Christian's code to be > useful for feature chaining. > > This may be an indication that, because in effect GeoServer has bound > together the concepts of namespace and workspace, the utility of workspaces > has been lost. Surely they were there to separate groups of data? If our > DataAccesses are forced apart into separate workspaces and we then have to > use a repository to allow them to communicate, workspaces serve no function. > > I think the GeoServer catalog as implemented is a work in progress. > Repository work should be informed by the future plans of the GeoServer > catalog. Justin? > > Copying the geoserver list. Yes, Jody, I am a naughty cc: spammer. Again. > Might as well just cc: everyone in my address book. > > Jody Garnett wrote: >> >> Bleck - sorry about the trouble Andrea. >> >>> getFeatureSources method from the repository. >>> >>> The problem here is that the semantics is not clear to me. There are data >>> store names, ids, namespaces, workspaces, prefixes and I have no idea >>> what >>> is what for geotools and geoserver. >> >> This seems to a be a problem with the information model presented by >> GeoServer. Christian I remain unconvinved that you should be allowing >> your code to reference DataStore from multiple GeoServer workspaces; I >> think they are designed be to separate. >> >> That is however a discussion for the geoserver-devel list. >> >>> Sorry, I will leave up this problem to Jody. >> >>> The only thing I could do is to add a method "getDataStores" returning >>> all >>> datastores and ValidationRunner can do his job. >> >> That seems to be what is needed; here is my "definition" for it: >> /** >> * List of available DataStore instances; these are considered to be >> * live/connected datastores under the management of the application >> * and should not be closed or otherwise harmed by client code. >> * <p> >> * >> * @return List of Managed DataStore instances >> */ >> public List<DataStore> getDataStores(); >> >>> Jody, for my registry implementations you could simply implement a method >>> throwing an "UnsupportedOperationException", I will investigate later. >> >> Will do - thanks. >> >> In reviewing your DSFinderRepository I notice you have almost the >> exact same design as that of DefaultRepository (helper methods to load >> in shapefiles; or other datastores indicated by properties files etc). >> >> Jody >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables unlimited >> royalty-free distribution of the report engine for externally facing server >> and web deployment. http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > -- > Ben Caradoc-Davies <[email protected]> > Software Engineer, CSIRO Exploration and Mining > Australian Resources Research Centre > 26 Dick Perry Ave, Kensington WA 6151, Australia > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
