I am very glad to see this feature moving ! For what it's worth and I may not be aware of all the intricacies, but I have developed a poor man's solution for this. The concept is based on assigning Features to (internet) domains/URLs. The current implementation is done with a Servlet filter and XSLT. Configuration is done with a properties file. So basically the pool of Features (layers/resources) is managed within GS as usual, but from this pool sets of Features are available only on particular URLs. Sets may overlap. Like said, the implementation is a kludge (that is why I was hesitant to publish this as a Community Extension), e.g. filtering a GetCapabilities, rendering only the assigned Features, but the general idea is quite flexible. The split is not tied to work/namespaces. Maybe this is the same idea as suggested in other reactions.
A config file looks like this (* is all features): site1.gis.nl=feature1,feature2,feature3 site2.gis.nl=feature2,feature5 www.gis.nl=* As said this now works with domains (and XML formats only!) but could be URLs as well. From the outside these domains look like different GS instances. I can make all relevant files available if needed offcourse. best, Just van den Broecke Ben Caradoc-Davies wrote: > On 08/12/09 21:35, Justin Deoliveira wrote: >> Yes, at this point in time a workspace == namespace, and we don't really >> have the notion of a map. When resource publishing split comes workspace >> will not be bound to a namespace. A namspace will simply be an attribute >> of a layer and not a container for layers. They will exist and be manged >> independently. > > [The crowd cheers!] > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
