From: Gabriel R. <gr...@op...> - 2012-01-26 23:03:51
|
On Thu, Jan 26, 2012 at 4:11 AM, Andrea Aime <and...@ge...> wrote: > On Wed, Jan 25, 2012 at 10:57 PM, Gabriel Roldan <gr...@op...> > wrote: >> >> Yeah, the concern makes complete sense. >> >> My hope is (with proper documentation) this makes it simpler. Like in >> if you want to configure a cached layer through the REST API, you >> should use the GWC REST API. And the way to do that is by having a >> steady xml/json representation of it. Storing it on the layer's >> metadata is a (very) convenient way of avoiding an extra storage >> mechanism for such a tightly coupled resource. But still I think the >> proper way to configure a cached layer for a geoserver layer would be >> through the gwc api. Makes sense? >> > > It does, yet at the same time we cannot avoid people to work against > the version embedded in the layer definition since it's out there and > right in their face. yeah, agreed. Just another point to have a stable/steady representation. > > Btw, don't know much about GWC rest api: how well is it integrated > with the GeoServer one? Thinking about security here, for example. > I honestly did not know the integrated GWC was exposing a rest api > to start with afaik it's been there since a long time (e.g. the seed form is part of the rest(ish) api. I'm just now getting into it more in depth though. One thing's sure you need to provide auth credentials to do anything that changes anything. Just tried and if you don't have write access to a given layer and try to do something (access to the layer's seed form,etc) it just won't be found. That said, I'm pretty sure that's just a side effect of the current tighter integration through GeoServerTileLayer. An in-depth assessment of proper security integration is no my todo list. Cheers, Gabriel |