Jody Garnett wrote:
> So this discussion does not seem to be finished yet ... and am hesitant
> of of folding this in until the REST api is fixed. Can we go half way
> and document what we are sure of and what is open for review?
Fixed... can you elaborate what "fixed" means?
>
> Additional comments inline:
>
> 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.
>
>
> It handles GET and PUT already; if we can just list the initial "rest
> index" page there; or link to the rest index page from our welcome
> screen that would be fine.
We could... but i am not sure I see a huge win. The people that ask for
a RESTful interface are not all that interested in making calls via a
web application form. And we don't really have a way to dynamically add
user interface links or components when an extension is around.
>
> > - 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 was focused on separating the data access from the data publication. I
> wanted to view publishing the vector falvour of a data set as a seperate
> concern (similar to the idea of how a layer is defined).
>
A layer is a published resource, that is it.
> To define a layer we bring together data resource and style. There are a
> few more steps like giving the result a title and description.
>
> To define a published feature type we need to bring together a data
> resource and some information about namespace/typeName (the same steps
> of giving the result a title and description apply).
Once we have a true data publishing split i can see us expanding on the
Layer class to include those properties that matter to services. For
instance, for WFS service the namespace/schema the layer should conform
to, etc...
>
> There are however some more steps that are on our roadmap:
> - we can have the result be the aggregation of two data sources (my
> example earlier)
> - the result can be generated according to a simple restriction (ie
> filter) or a more complicated mapping (ie community schemas)
> - some operations (ie WPS) may be allowed on this resource
>
> 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.
>
>
> We could have links from the resource data page to the various places it
> is published (the same data may be available in many formats and
> visualized using several different named styles (and visualized used a
> user supplied style if SLD is allowed).
>
>
>
> 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.
>
>
> It is too bad you could not consider nested layers to mirror what is
> going on in the capabilities document?
> /layers/layer1
> /layers/layer1/child1
> /layers/layer2
Hmmm... I disagree here. That is about a single service, WMS. This api
is all about internal resources. The WMS "view" should be something
separate imho.
>
>
> So:
>
> /layers/{layername} would simply be a list of references to resources,
> no extra publishing information except for "what is this layer
> publishing".
>
>
> That does not really work for me since the layer definition brings
> together additional information beyond the resource (name, title, scale,
> srs, style settings etc...). It is better to think of it *as* a resoure
> (namely a visualization). When you change the settings on that page you
> are changing the settings for this visualization.
>
> A mistake we made earlier was to try and load up the resource definition
> with too much information (like a default style) bluring the line
> between data and layer. We should try and keep it clear.
>
It seems this conversation is all about the configuration model, not
about the rest interfaces around it. Can we break out a separate thread
for these issues?
>
> /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.
>
>
> Yep that is what I am trying to avoid; feature type is not a layer and
> vice versa...
>
>
> /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?
>
>
> How to do wps is fairly clear from the ESRI stuff .... it shows up in
> your configuration as what operations you allow for a particular feature
> type. And then when you make a page for the feature collection you can
> have links to the allowed operations.
>
> Cheers,
> Jody
>
--
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
