On Wed, Feb 25, 2009 at 8:13 AM, Justin Deoliveira <[email protected]>wrote:
> 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?
Fixed in scope; nailed down, not going to change ...
>
> 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.
Okay; so from there we treat GML and PNG the same? The reason I ask is
trying to sort out if we need ...
/namespace/ <-- used to configure and/or define the schmea associated with
this namespace
/namespace/featureType <-- used to define / refine how a resource is
presented in this namespace
> 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...
Okay that works for me; layer is a published resource is a nice clean
definition.
>
>
>>
>> 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.
You are correct; I did not have your information about a layer being any
published resource (ie published for WMS or WFS or whatever).
> This api is all about internal resources.
Am I correct in my understanding here - this API is all about our internal
configuration (so we can supply the information that is later turned into a
WMS capabilities or a WFS capabilities).
> The WMS "view" should be something separate imho.
I understand the seperation; however I am a bit puzzled on how to proceed;
the wms tree structure would be nice to present as a tree - especially since
not all nodes in the wms tree are named?
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?
I was going over the documentation on the rest module; and trying to see if
it represented a stable picture of geoserver's configuration.
It appears I am missing some information in order to undertand what is
presented.
Jody
------------------------------------------------------------------------------
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
