Hi,
I am looking at adding support for REST configuration of XSLT transformations.
Earlier Justin suggested I should try to merge them into the existing tree under
the WFS section, which I'm trying to do but stumbling into a couple of design
issues in the existing URLs
Here is the current mapping:
<entry>
<key><value>/services/wms/settings</value></key>
<value>wmsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wms/settings.{format}</value></key>
<value>wmsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wms/{workspace}/settings</value></key>
<value>wmsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wms/{workspace}/settings.{format}</value></key>
<value>wmsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wfs/settings</value></key>
<value>wfsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wfs/settings.{format}</value></key>
<value>wfsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wfs/{workspace}/settings</value></key>
<value>wfsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wfs/{workspace}/settings.{format}</value></key>
<value>wfsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wcs/settings</value></key>
<value>wcsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wcs/settings.{format}</value></key>
<value>wcsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wcs/{workspace}/settings</value></key>
<value>wcsSettingsFinder</value>
</entry>
<entry>
<key><value>/services/wcs/{workspace}/settings.{format}</value></key>
<value>wcsSettingsFinder</value>
</entry>
One first evident issue is that the set of mappings is static, and we
only have wfs/wcs/wms.
How about wps and csw?
The resources should be changed to follow the pluggable nature of
services and become
something like:
<entry>
<key><value>/services/{service}/settings</value></key>
<value>serviceSettingsFinder</value>
</entry>
so that resources for non core OGC services show up.
The other issue is that the above layout is not extensible without conflicts.
See hits:
/services/wfs/{workspace}/settings
And the transformations would have to be located at:
/services/wfs/transforms // list all
/services/wfs/transforms?featureType={featureType} // list feature
type specific transforms (more on this later)
/services/wfs/transforms/{transform} // the xml config
/services/wfs/transforms/{transform}.xslt // the xslt file, mimicking
styles approach
Now, what if a workspace is named "transforms"? We have a conflict.
Generally speaking resources should be designed so that there is a container
separating the varying part from the root, so that it's possible to
add side by side
more containers without conflicts, something like this:
/services/wfs/workspaces/{workspace}/settings
This way we could have workspaces, settings, transform and more containers to
come if other WFS output formats need configuration (conceivably we could have
a ogr2ogr node for example).
Even in case the above is considered ok, how do we handle things now that
the above urls got to be part of 2.2.1?
Should I just give up the original plan and put the transforms
configuration right at the root?
Or we deprecate the above urls, and have things work also off the urls
I've proposed
for the stable series, keeping the possibility of a conflict, and make
sure that on
trunk we don't support /services/wfs/{workspace}/settings but only
/services/wfs/workspaces/{workspace}/settings ?
Btw, about using a query param to locate the feature types instead of
placing the
transformations right under the feature type itself, it's about being
able to locate
and manage the transformations: it's not conceivable that one has to scan the
entire resource tree in order to find the available transformation, it would
require an eternity if there is a lot of feature types around.
It's actually a topic that has been popping up internally too, like,
how do I find
the list of all vector layers? Right now one has to go through each and every
feature type, or scan each and every layer and see what it's connected to:
it's a lot of requests, for the future we should also think about how to handle
bulk requests of sorts without requiring to jump between a million resources.
Cheers
Andrea
--
Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------