Rob Atkinson wrote: > I notice you talk about workspaces in one sentence then "a map" in > another sentence. My understanding is that workspaces are bound to > default namespaces (app-schema will get you out of that, but I've yet > to get my head around whether workspaces just become an impedence > overhead, or whether they effectively get bound to differend back-end > operational systems). 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. > > A "map" has a completely different set of semantics. > > I see no particular reason a namespace or back-end operational system > is necessarily the only way of splitting up the geoserver services - > you are building a very inflexible solution IMHO. I would like to have > virtual services where you can put any resource the service should > offer, not just those defined by a namespace (either a made-up one or > an app-schema). > Yeah, so do I. And while I am at it I would also like to win the lottery tomorrow. We are at a middle ground. What you are asking for is coming when the full blown resource publishing split occurs. But this is an intermediate step.
> Can we not have a first-class concept of a service, and then map one > or more workspaces to it as a convenience mechanism? > > I'd also like a single workspace to be available via multiple virtual > services to different audiences (simple, complete, and transactional > for example). > > i.e. the mix of functionality for a single workspace is as valid a > reason for virtualisation as partitioning the set of resources across > workspaces. > > Rob > > On Tue, Dec 8, 2009 at 4:48 AM, Justin Deoliveira <[email protected]> > wrote: >> Hi all, >> >> Recently OpenGeo has received funding to implement the idea of virtual >> services in a limited form. The basic idea is to provide service >> endpoints for each workspace so you can make requests like: >> >> http://.../geoserver/topp/wfs?request=.... >> >> Basically what we currently do with workspace filters as a query >> parameter with some additions. The full GSIP is written up here: >> >> http://geoserver.org/display/GEOS/GSIP+44+-+Virtual+services+with+workspaces >> >> One thing to note is how this plays with resource publishing split since >> there is some overlap in this functionality and what resource pub split >> will provide. I wrote up some notes at the end of the proposal on this. >> But the gist of it is that the upgrade path should be quite smooth. >> >> Actually this work fills one of the gaps that was shot in the resource >> pub proposal by Jody in that it did not explicitly specify the ability >> to specify a map in a url path as opposed to specifying it in the query >> string. >> >> Comments and feedback welcome. >> >> -Justin >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> >> ------------------------------------------------------------------------------ >> Join us December 9, 2009 for the Red Hat Virtual Experience, >> a free event focused on virtualization and cloud computing. >> Attend in-depth sessions from your desk. Your couch. Anywhere. >> http://p.sf.net/sfu/redhat-sfdev2dev >> _______________________________________________ >> Geoserver-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >> -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ 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
