On Mon, 2009-02-23 at 10:45 +1100, Jody Garnett wrote:
> The proposal is light on details; but then again not much needs to be
> changed here right? You are only looking to migrate a community module
> to an extension. The documentation is missing the configuration
> examples section (made me wonder if the sample requests page can be
> extended to include REST API use?)
>
Without looking at the sample requests page, I seem to recall that it is
already making HTTP requests internally, so it should be pretty easy to
extend it to allow REST requests. We will probably want to rethink how
the sample requests are stored on-disk though, to allow for PUTs.
However, it seems more in the spirit of REST to just encourage
developers to explore the API with a regular web browser (and encourage
REST service developers to take care that the hierarchies they present
are explorable with a web browser.) An advantage of this approach is
that REST services provided by extensions can also implement it, whereas
it's more awkward to put demo requests for extensions in the release
configuration when those extensions aren't included in the release.
Of course, those two approaches are not incompatible.
> So as we review this the main thing is to make sure the style is
> future proof correct? That what we outline here will not have to be
> modified in the future...
>
> So I have a couple of questions (please understand that this is just
> me not keeping up with geoserver discussions and not me knocking the
> design)
> - workspaces - how does this fit in and what is the relationship with
> namespaces
in 1.7.x, workspaces have a 1:1 relationship with namespaces.
in 2.0.x, my understanding is that we'll be providing workspaces as a
purely configuration-side aspect of a data set; they will not affect
publishing at all but administrators see datastores grouped by
workspace, which they can freely define to help with organizing large
datadirs. Published map services will also provide grouping, but need
have no particular relationship to the workspaces.
> - structures seems to be datastore then feature type? We have had one
> case where geoserver was configured to "combine" data from two
> cascaded WFS's were combined into the same published featuretype. Do
> we need to consider namespace/featureType as representing the publish
> to WFS (similar to how layer represents publish to WMS)
If I get you right, you're suggesting that we keep the current
/layers/{layername} endpoint and add a parallel hierarchy for each
service (/publishedcoverages/{coverageid}
and /publishedfeaturetypes/{featuretypeid}). I think we should try to
better convey the fact that WFS, WCS, and WMS expose different aspects
of the same data (to avoid having to create a layer config for each
layer for each service). That is,
/layers/{layername}/wms would be the wms configuration for some layer,
with .../wfs and .../wcs for the wfs and wcs configurations
respectively.
This sort of leads into an idea I was briefly discussing with Justin in
IRC a couple of weeks ago; namely, that of doing away with the idea of
layergroups, in favor of layers simply allowing multiple resources. So:
/layers/{layername} would simply be a list of references to resources,
no extra publishing information except for "what is this layer
publishing".
/layers/{layername}/wms would be the WMS settings: default style,
alternative styles, default SRS, etc. The 'alternative styles' option
would probably need to be disabled/prohibited when the layer is
configured to expose multiple datastores.
/layers/{layername}/wfs would be the WFS settings like maxfeatures, etc,
and be disabled unless the layer exposed a single featuretype resource.
/layers/{layername}/wcs would be the WCS settings (no examples come to
mind) and be disabled unless the layer exposed a single coverage
resource.
And so on for whatever future services extensions may provide. I will
admit to being fairly uninformed with regard to WPS; does it reasonably
fit into this structure, or are processes sufficiently different that it
doesn't make sense to talk about them in layers?
--
David Winslow
OpenGeo - http://opengeo.org/
> Jody
>
> PS. I am not sure who is doing the template but if they can replace
> [~jgarnett] with [~jive] my name will show up correctly
>
> On Thu, Feb 19, 2009 at 4:15 AM, Justin Deoliveira
> <[email protected]> wrote:
> Hi all,
>
> I have put together a proposal for moving the rest
> configuration module
> to an official extension.
>
> http://geoserver.org/display/GEOS/GSIP+33+-+REST+configuration
> +module
>
> Open the feedback gates.
>
> -Justin
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing
> the Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the
> source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________ Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
