Hey Ben,
Thanks for the input. Some comments line.
On Sun, Nov 6, 2011 at 8:13 PM, Ben Caradoc-Davies
<[email protected]> wrote:
> Justin,
>
> I am a bit concerned that more functionality is being layered on top of an
> incomplete model. Am I missing something or is there still an assumption of
> a one-to-one mapping between workspaces and namespaces? I support the idea
> of having per-workspace services, but until a workspace can contain
> multiple namespaces, this is of no use to anyone delivering related feature
> types in different namespaces.
>
> Understood, and indeed the long term vision is to break the coupling, and
simply have namespace be an attribute of a layer, since its a publishing
concern, not a data organizational one (at least not from an admin
perspective). The short term reality is that there is a one to one
relationship there to preserve backward compatibility. It actually should
be pretty straight forward to remove this constraint, but up until now it
seems no one has had a mandate to do so.
> app-schema users have on many occasions asked for the ability to deliver
> multiple profiles of their services from a GeoServer. For example, a
> service may be configured to deliver sa:LocatedSpecimen and its related
> om:Observations. Because a WFS service can only deliver a feature type
> once, it is not possible to deliver two different mappings of the data or
> two different encoding profiles. This would be possible if we had true
> workspaces workspaceOne and workspaceTwo that could each contain their own
> sa and om namespaces and each had their own WFS service endpoint. Without
> this functionality, users end up with multiple identical GeoServer
> instances differing only in their data directory.
>
Right, again I think this becomes easy/easier to achieve once we break the
workspace / namespace binding.
>
> In my view, the simplest way to regularise the delivery of services would
> be to not have a separate global service; this should just be the local
> service of the default workspace. Once you have a namespace and feature
> types appearing in multiple workspaces, you will not be able to determine
> which should be used for a "global service".
>
This is a fairly WFS centric view in which a "server" is divided up into
"services" by wfs namespace, and one that is imo orthogonal to the virtual
services approach, which is more about the admin side of things.
> As an aside, as far as I understand it, the resource-publishing split has
> never been completed:
> https://jira.codehaus.org/**browse/GEOS-2881<https://jira.codehaus.org/browse/GEOS-2881>
> http://geoserver.org/display/**GEOS/GSIP+36+-+Resource+-+**
> Publishing+Split+and+Virtual+**Configuration<http://geoserver.org/display/GEOS/GSIP+36+-+Resource+-+Publishing+Split+and+Virtual+Configuration>
Unfortunately this has been more or less abandoned. While nice from a
theoretical point of view practically I believe it is just too invasive an
approach, and strays quite a bit from the way geoserver works today. It
requires a serious mandate, lots of funding, and really it is a change that
is on the same scale as the catalog/configuration rewrite... so
realistically would cause us to spend probably a full release cycle
flushing out regressions.
The workspace approach to virtual services was a much less ambitious
approach, and while admittedly less elegant than a full resource -
publishing split, it is capable of solving most of the same issues. So it
was chosen mostly for pragmatic reasons.
>
> Kind regards,
> Ben.
>
>
> On 07/11/11 06:15, Justin Deoliveira wrote:
>
>> Hi all,
>>
>> I just put together a proposal for next round of virtual services, and
>> the ability to configure services on a workspace by workspace basis.
>>
>> http://geoserver.org/display/**GEOS/GSIP+66+-+Workspace+**
>> Local+Services<http://geoserver.org/display/GEOS/GSIP+66+-+Workspace+Local+Services>
>>
>> Feedback much appreciated.
>>
>> -Justin
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>>
>>
> --
> Ben Caradoc-Davies <[email protected]>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
