[Geoserver-devel] asking for feedback on gwc integration improvements

Gabriel_Roldan2 · January 24, 2012, 5:32pm

Hello all,

I'd like to ask for your opinions on a number of GWC integration
improvements, as a continuation of the earlier work presented a couple
weeks ago, for which I'm copying the screenshots bellow.
These are the final bits for the long standing work described at
http://jira.codehaus.org/browse/GEOS-4460

The goal is to make the integrated gwc configuration much easier,
allowing to configure both gridsets and cached layers through the UI.

But besides what can be inferred from the screenshots, I wanted to
gather some feedback on the following issues:
- When we stopped faking a gwc's WMSLayer per GeoServer layer/group,
we started storing the geoserver's tile layer configuration options in
each Layer(Group)Info's metadata map, as a set of properties
(GWC.enabled, GWC.gutter, GWC.gridsets, etc). Now, while enabling to
configure almost every aspect of the cached layer, instead of storing
a single metadata entry for each cached layer property, I'd rather
store the whole tile layer configuration as a single metadata entry,
in its JSON representation. Earlier experience in doing that is the
storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
LayerGroupInfo metadata map, and it seems to be working well. So if
there's no opposition I'd store the tile layer configuration as a
single JSON entry in the metadata map, allowing for the natural
evolution of the cached layer configuration without extra bloating of
the metadata map (backwards compatible with the current set of
entries, of course).

- The other things I'd like to gather feedback about are related to the UI.
* To start with, I got some feedback on that the "Cached Layers" menu
entry on the "Data" menu is kind of awkward/confusing. As background
information, the only reason for that page to exist instead of being
integrated directly with the regular "Layers" page is that GWC
supports also externally configured tile layers, which wouldn't fit on
the layers/layergroup pages. So the proposal is to get rid of that
menu entry, and instead integrate the list of cached layers (both
geoserver's and external) as a tab in the "GeoWebCache" configuration
page.

* Rename the "GeoWebCache" menu entry in the settings menu. Looks like
people need to know what "GeoWebCache" is. It'd be better to call that
menu entry something more related to what it does, like "Tile Cache"
or something like that. Suggestions welcomed.

* Make the LayerGroup edit page tabbed. It's getting messy
<http://skitch.com/groldan/g1s3j/11-tilelayer-config-for-layergroup>\.
It'd be better if it had tabs just like the Layer/Resource edit page,
so that tile caching has it's own tab:
<http://skitch.com/groldan/g1s3r/10-tilelayer-config-for-layerinfo>

TIA for all and any feedback,
Gabriel.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime4 · January 25, 2012, 1:33pm

On Tue, Jan 24, 2012 at 6:32 PM, Gabriel Roldan <groldan@anonymised.com…> wrote:

Hello all,

I’d like to ask for your opinions on a number of GWC integration
improvements, as a continuation of the earlier work presented a couple
weeks ago, for which I’m copying the screenshots bellow.

They look good (most of them at least)

These are the final bits for the long standing work described at
http://jira.codehaus.org/browse/GEOS-4460

The goal is to make the integrated gwc configuration much easier,
allowing to configure both gridsets and cached layers through the UI.

But besides what can be inferred from the screenshots, I wanted to
gather some feedback on the following issues:

When we stopped faking a gwc’s WMSLayer per GeoServer layer/group,
we started storing the geoserver’s tile layer configuration options in
each Layer(Group)Info’s metadata map, as a set of properties
(GWC.enabled, GWC.gutter, GWC.gridsets, etc). Now, while enabling to
configure almost every aspect of the cached layer, instead of storing
a single metadata entry for each cached layer property, I’d rather
store the whole tile layer configuration as a single metadata entry,
in its JSON representation. Earlier experience in doing that is the
storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
LayerGroupInfo metadata map, and it seems to be working well. So if
there’s no opposition I’d store the tile layer configuration as a
single JSON entry in the metadata map, allowing for the natural
evolution of the cached layer configuration without extra bloating of
the metadata map (backwards compatible with the current set of
entries, of course).

Works for me. Wondering, why JSON and not XML?
If you look at SQL views setups they are stored as xml instead, making
it look more “natural” if you look at the xml file (which you will see when
using rest config) and won’t require mixing technologies when building
rest requests.

The other things I’d like to gather feedback about are related to the UI.

To start with, I got some feedback on that the “Cached Layers” menu
entry on the “Data” menu is kind of awkward/confusing. As background
information, the only reason for that page to exist instead of being
integrated directly with the regular “Layers” page is that GWC
supports also externally configured tile layers, which wouldn’t fit on
the layers/layergroup pages. So the proposal is to get rid of that
menu entry, and instead integrate the list of cached layers (both
geoserver’s and external) as a tab in the “GeoWebCache” configuration
page.

Works for me. Wondering if the GWC page could get too busy though…
another option could be to have a Tile Cache group in the side menu
and have the tabs be menu entries there. At the same time screens are
getting larger but not taller, I guess we’re running out of vertical space eh?

Rename the “GeoWebCache” menu entry in the settings menu. Looks like
people need to know what “GeoWebCache” is. It’d be better to call that
menu entry something more related to what it does, like “Tile Cache”
or something like that. Suggestions welcomed.

Tile Cache sounds fine

Make the LayerGroup edit page tabbed. It’s getting messy
<http://skitch.com/groldan/g1s3j/11-tilelayer-config-for-layergroup>.
It’d be better if it had tabs just like the Layer/Resource edit page,
so that tile caching has it’s own tab:
<http://skitch.com/groldan/g1s3r/10-tilelayer-config-for-layerinfo>

Yep

This looks like a very large amount of changes. Is it going to land on
trunk only? Eventually for some time, so that we can kick its tires
before backporting on 2.1.x?
That said, some of the things we did only on trunk like rendering
transformations and time/elevation support with an intention of
backporting later actually never came back, there is an objective
difficulty in doing a backport one/two months later when the code
has had the time to move.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Gabriel_Roldan2 · January 25, 2012, 4:54pm

Hey Andrea, thanks for the great feedback.
comments inline.

On Wed, Jan 25, 2012 at 10:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Tue, Jan 24, 2012 at 6:32 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Hello all,

I'd like to ask for your opinions on a number of GWC integration
improvements, as a continuation of the earlier work presented a couple
weeks ago, for which I'm copying the screenshots bellow.

They look good (most of them at least)

These are the final bits for the long standing work described at
http://jira.codehaus.org/browse/GEOS-4460

The goal is to make the integrated gwc configuration much easier,
allowing to configure both gridsets and cached layers through the UI.

But besides what can be inferred from the screenshots, I wanted to
gather some feedback on the following issues:
- When we stopped faking a gwc's WMSLayer per GeoServer layer/group,
we started storing the geoserver's tile layer configuration options in
each Layer(Group)Info's metadata map, as a set of properties
(GWC.enabled, GWC.gutter, GWC.gridsets, etc). Now, while enabling to
configure almost every aspect of the cached layer, instead of storing
a single metadata entry for each cached layer property, I'd rather
store the whole tile layer configuration as a single metadata entry,
in its JSON representation. Earlier experience in doing that is the
storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
LayerGroupInfo metadata map, and it seems to be working well. So if
there's no opposition I'd store the tile layer configuration as a
single JSON entry in the metadata map, allowing for the natural
evolution of the cached layer configuration without extra bloating of
the metadata map (backwards compatible with the current set of
entries, of course).

Works for me. Wondering, why JSON and not XML?
If you look at SQL views setups they are stored as xml instead, making
it look more "natural" if you look at the xml file (which you will see when
using rest config) and won't require mixing technologies when building
rest requests.

Actually, I'll look into how SQL views are stored. I agree XML would
fit more naturally. Thanks for the tip.

- The other things I'd like to gather feedback about are related to the
UI.
* To start with, I got some feedback on that the "Cached Layers" menu
entry on the "Data" menu is kind of awkward/confusing. As background
information, the only reason for that page to exist instead of being
integrated directly with the regular "Layers" page is that GWC
supports also externally configured tile layers, which wouldn't fit on
the layers/layergroup pages. So the proposal is to get rid of that
menu entry, and instead integrate the list of cached layers (both
geoserver's and external) as a tab in the "GeoWebCache" configuration
page.

Works for me. Wondering if the GWC page could get too busy though...
another option could be to have a Tile Cache group in the side menu
and have the tabs be menu entries there. At the same time screens are
getting larger but not taller, I guess we're running out of vertical space
eh?

Works for me that way too. Thinking of how such a menu would look like:
- Tile Cache
-- Global Settings --> <http://skitch.com/groldan/sets/gqn/gwc-ui>
-- Tile Matrix Sets --> GridSets list with access to configuration.
Called TileMatrixSet instead cause it comes from an actual spec rather
than being GWC specific?
-- Cached Layers --> list of cached layers (quota usage, common
operations like seed/truncate)

Besides, at some point the gwc offered services (wms-c, tms, wmts,
etc) should have its own entry besides wms/wcs/wfs. But for the time
being it'd be overwhelming as gwc is not really designed with that
sort of (basic) configurability.

* Rename the "GeoWebCache" menu entry in the settings menu. Looks like
people need to know what "GeoWebCache" is. It'd be better to call that
menu entry something more related to what it does, like "Tile Cache"
or something like that. Suggestions welcomed.

Tile Cache sounds fine

k, guess I'll stick to it.

* Make the LayerGroup edit page tabbed. It's getting messy
<http://skitch.com/groldan/g1s3j/11-tilelayer-config-for-layergroup>\.
It'd be better if it had tabs just like the Layer/Resource edit page,
so that tile caching has it's own tab:
<http://skitch.com/groldan/g1s3r/10-tilelayer-config-for-layerinfo>

Yep

This looks like a very large amount of changes. Is it going to land on
trunk only? Eventually for some time, so that we can kick its tires
before backporting on 2.1.x?

_trunk only_, plus a strong desire to get a stable branch out of 2.2.x
sooner rather than later. Although I'm not sure for how long we plan
to keep 2.1.x as _the_ stable branch, it looks to me like 2.2.x is in
need to get some real work testing so we should start releasing betas
out of it.

That said, some of the things we did only on trunk like rendering
transformations and time/elevation support with an intention of
backporting later actually never came back, there is an objective
difficulty in doing a backport one/two months later when the code
has had the time to move.

I'll probably maintain a 2.1.x integration branch on git. First,
because I want this to get tested on trunk and get as many bug fixes
as possible before even thinking of backporting to 2.1.x. But, _if_ we
found out it deserves to be on the 2.1.x branch, the port shouldn't be
that hard because both 2.2.x and 2.1.x and based on the same gwc
version. There are a couple things that the 2.2.x version has that the
2.1.x backport won't though: integration with TIME/ELEVATION
configuration for example. Can't remember if something else.

Cheers,
Gabriel

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime4 · January 25, 2012, 5:47pm

On Wed, Jan 25, 2012 at 5:54 PM, Gabriel Roldan <groldan@anonymised.com…> wrote:

trunk only, plus a strong desire to get a stable branch out of 2.2.x
sooner rather than later. Although I’m not sure for how long we plan
to keep 2.1.x as the stable branch, it looks to me like 2.2.x is in
need to get some real work testing so we should start releasing betas
out of it.

I also agree it would be hight time to start releasing betas and hardening
trunk. It has a number of good features that are working, it already feels
beta quality if not better.

Wondering what the others devs think about this topic (maybe we should
start another thread to discuss it…)

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Justin_Deoliveira · January 25, 2012, 5:51pm

On Wed, Jan 25, 2012 at 10:47 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Jan 25, 2012 at 5:54 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

trunk only, plus a strong desire to get a stable branch out of 2.2.x
sooner rather than later. Although I’m not sure for how long we plan
to keep 2.1.x as the stable branch, it looks to me like 2.2.x is in
need to get some real work testing so we should start releasing betas
out of it.

I also agree it would be hight time to start releasing betas and hardening
trunk. It has a number of good features that are working, it already feels
beta quality if not better.

Wondering what the others devs think about this topic (maybe we should
start another thread to discuss it…)

+1 on another thread. The main thing from my point of view is the security work… which is a pretty huge change, so I would like to put off any betas until that has landed on trunk, which should start happening soon. Will provide more info about that in the separate thread.

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

David_Winslow · January 25, 2012, 9:39pm

The REST API exposes metadata attributes in both JSON and XML formats, so it could be argued that either format is equally convenient. I think the big problem is documentation though - without digging into GeoServer’s code is it possible to figure out what keys to use and what the values should look like?

When I work with the REST API I often find myself making a configuration through the web UI so I can get a “template” object. This is ok as far as it goes, but I’m never confident I know about the acceptable range of values for a setting, etc. That goes double when the value is some complicated object instead of a simple string.

Just throwing it out there.

–
David Winslow
OpenGeo - http://opengeo.org/

On Wed, Jan 25, 2012 at 11:54 AM, Gabriel Roldan <groldan@anonymised.com> wrote:

Hey Andrea, thanks for the great feedback.
comments inline.

On Wed, Jan 25, 2012 at 10:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Tue, Jan 24, 2012 at 6:32 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Hello all,

I’d like to ask for your opinions on a number of GWC integration
improvements, as a continuation of the earlier work presented a couple
weeks ago, for which I’m copying the screenshots bellow.

They look good (most of them at least)

These are the final bits for the long standing work described at
http://jira.codehaus.org/browse/GEOS-4460

The goal is to make the integrated gwc configuration much easier,
allowing to configure both gridsets and cached layers through the UI.

But besides what can be inferred from the screenshots, I wanted to
gather some feedback on the following issues:

When we stopped faking a gwc’s WMSLayer per GeoServer layer/group,
we started storing the geoserver’s tile layer configuration options in
each Layer(Group)Info’s metadata map, as a set of properties
(GWC.enabled, GWC.gutter, GWC.gridsets, etc). Now, while enabling to
configure almost every aspect of the cached layer, instead of storing
a single metadata entry for each cached layer property, I’d rather
store the whole tile layer configuration as a single metadata entry,
in its JSON representation. Earlier experience in doing that is the
storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
LayerGroupInfo metadata map, and it seems to be working well. So if
there’s no opposition I’d store the tile layer configuration as a
single JSON entry in the metadata map, allowing for the natural
evolution of the cached layer configuration without extra bloating of
the metadata map (backwards compatible with the current set of
entries, of course).

Works for me. Wondering, why JSON and not XML?
If you look at SQL views setups they are stored as xml instead, making
it look more “natural” if you look at the xml file (which you will see when
using rest config) and won’t require mixing technologies when building
rest requests.

Actually, I’ll look into how SQL views are stored. I agree XML would
fit more naturally. Thanks for the tip.

The other things I’d like to gather feedback about are related to the
UI.

To start with, I got some feedback on that the “Cached Layers” menu
entry on the “Data” menu is kind of awkward/confusing. As background
information, the only reason for that page to exist instead of being
integrated directly with the regular “Layers” page is that GWC
supports also externally configured tile layers, which wouldn’t fit on
the layers/layergroup pages. So the proposal is to get rid of that
menu entry, and instead integrate the list of cached layers (both
geoserver’s and external) as a tab in the “GeoWebCache” configuration
page.

Works for me. Wondering if the GWC page could get too busy though…
another option could be to have a Tile Cache group in the side menu
and have the tabs be menu entries there. At the same time screens are
getting larger but not taller, I guess we’re running out of vertical space
eh?

Works for me that way too. Thinking of how such a menu would look like:

Tile Cache
– Global Settings → <http://skitch.com/groldan/sets/gqn/gwc-ui>
– Tile Matrix Sets → GridSets list with access to configuration.
Called TileMatrixSet instead cause it comes from an actual spec rather
than being GWC specific?
– Cached Layers → list of cached layers (quota usage, common
operations like seed/truncate)

Besides, at some point the gwc offered services (wms-c, tms, wmts,
etc) should have its own entry besides wms/wcs/wfs. But for the time
being it’d be overwhelming as gwc is not really designed with that
sort of (basic) configurability.

Rename the “GeoWebCache” menu entry in the settings menu. Looks like
people need to know what “GeoWebCache” is. It’d be better to call that
menu entry something more related to what it does, like “Tile Cache”
or something like that. Suggestions welcomed.

Tile Cache sounds fine

k, guess I’ll stick to it.

Make the LayerGroup edit page tabbed. It’s getting messy
<http://skitch.com/groldan/g1s3j/11-tilelayer-config-for-layergroup>.
It’d be better if it had tabs just like the Layer/Resource edit page,
so that tile caching has it’s own tab:
<http://skitch.com/groldan/g1s3r/10-tilelayer-config-for-layerinfo>

Yep

This looks like a very large amount of changes. Is it going to land on
trunk only? Eventually for some time, so that we can kick its tires
before backporting on 2.1.x?

trunk only, plus a strong desire to get a stable branch out of 2.2.x
sooner rather than later. Although I’m not sure for how long we plan
to keep 2.1.x as the stable branch, it looks to me like 2.2.x is in
need to get some real work testing so we should start releasing betas
out of it.

That said, some of the things we did only on trunk like rendering
transformations and time/elevation support with an intention of
backporting later actually never came back, there is an objective
difficulty in doing a backport one/two months later when the code
has had the time to move.

I’ll probably maintain a 2.1.x integration branch on git. First,
because I want this to get tested on trunk and get as many bug fixes
as possible before even thinking of backporting to 2.1.x. But, if we
found out it deserves to be on the 2.1.x branch, the port shouldn’t be
that hard because both 2.2.x and 2.1.x and based on the same gwc
version. There are a couple things that the 2.2.x version has that the
2.1.x backport won’t though: integration with TIME/ELEVATION
configuration for example. Can’t remember if something else.

Cheers,
Gabriel

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Gabriel_Roldan2 · January 25, 2012, 9:57pm

On Wed, Jan 25, 2012 at 6:39 PM, David Winslow <dwinslow@anonymised.com> wrote:

The REST API exposes metadata attributes in both JSON and XML formats, so it
could be argued that either format is equally convenient. I think the big
problem is documentation though - without digging into GeoServer's code is
it possible to figure out what keys to use and what the values should look
like?

When I work with the REST API I often find myself making a configuration
through the web UI so I can get a "template" object. This is ok as far as
it goes, but I'm never confident I know about the acceptable range of values
for a setting, etc. That goes double when the value is some complicated
object instead of a simple string.

Just throwing it out there.

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?

Cheers,
Gabriel

Andrea_Aime4 · January 26, 2012, 7:11am

On Wed, Jan 25, 2012 at 10:57 PM, Gabriel Roldan <groldan@anonymised.com1…> 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.

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

Cheers
Andrea

–

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

Gabriel_Roldan2 · January 26, 2012, 11:03pm

On Thu, Jan 26, 2012 at 4:11 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Wed, Jan 25, 2012 at 10:57 PM, Gabriel Roldan <groldan@anonymised.com>
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

Gabriel_Roldan2 · January 27, 2012, 12:32am

On Wed, Jan 25, 2012 at 10:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Now, while enabling to
configure almost every aspect of the cached layer, instead of storing
a single metadata entry for each cached layer property, I'd rather
store the whole tile layer configuration as a single metadata entry,
in its JSON representation. Earlier experience in doing that is the
storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
LayerGroupInfo metadata map, and it seems to be working well. So if
there's no opposition I'd store the tile layer configuration as a
single JSON entry in the metadata map, allowing for the natural
evolution of the cached layer configuration without extra bloating of
the metadata map (backwards compatible with the current set of
entries, of course).

Works for me. Wondering, why JSON and not XML?
If you look at SQL views setups they are stored as xml instead, making
it look more "natural" if you look at the xml file (which you will see when
using rest config) and won't require mixing technologies when building
rest requests.

ok, but: if my understanding is correct, in order to do so I'd need to
register an XStream Converter inside XStreamPersister. For
VirtualTable and everything else so far it's been easy because they
were added directly. But the gwc integration has the "philosophy" of
being pluggable/decoupled, which makes this trickier.
First option I can think of is an extension point, say,
GeoServerConverter, that the XStreamPersister.init() method looks up
for and registers all found implementations to the XStream instance.
That is step one. But what happens if this custom gwc converted
follows the same approach than the VirtualTableConverter
(e.g. <entry name="GWC.tileLayer"><some><customXml/></some></entry>)
and then the gwc jars are removed from the classpath, including the
geoserver's gwc integration jar. Wouldn't that mapping bomb?

While most of you sleep, I'll try to find out.

Cheers,
Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · February 6, 2012, 3:13pm

WRT storing the tile layer configuration as part of the layer/group
metadata map:

The more I think about it, the more I'm inclined _not_ to store the
tile layer config as part of the metadata map.
As it evolved enough as not to be any "simple" property of the map, I
think trying to make it fit is overkill and it would rather be better
a gwc only thing, like in gwc being in charge of maintaining that
configuration on its own, rather than squeezing it into the metadata
map.
Rationale:
- People using the geoserver REST API will (rightfully) try to
configure the tile layer through the layer's REST resource instead of
through GWC's REST API.
- Not all layers may be configured with an associated tile layer,
which kind of forces gwc to do a full scan of layers just to find out
which ones have the config on its metadata map.
- The REST representations of layers and layer groups would be
unnecessarily bloated

Rest assured having the tile layer configuration so close to the
layer/group is "handy". Specially because of the monolithic gwc
configuration file, which would have to be overridden as a whole
every time a layer config changes. Which makes me think that perhaps
we could get the better of both worlds by keeping the geoserver tile
layer configuration as a separate file next to the layer.xml or
layergroup config file instead, as there's no room at least on the gwc
stable branch to change its configuration subsystem to stop being
monolithic.

Thoughts?

TIA,
Gabriel

On Thu, Jan 26, 2012 at 9:32 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

On Wed, Jan 25, 2012 at 10:33 AM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

Now, while enabling to
configure almost every aspect of the cached layer, instead of storing
a single metadata entry for each cached layer property, I'd rather
store the whole tile layer configuration as a single metadata entry,
in its JSON representation. Earlier experience in doing that is the
storage of AuthorityURLInfo as a JSON entry in the LayerInfo and
LayerGroupInfo metadata map, and it seems to be working well. So if
there's no opposition I'd store the tile layer configuration as a
single JSON entry in the metadata map, allowing for the natural
evolution of the cached layer configuration without extra bloating of
the metadata map (backwards compatible with the current set of
entries, of course).

Works for me. Wondering, why JSON and not XML?
If you look at SQL views setups they are stored as xml instead, making
it look more "natural" if you look at the xml file (which you will see when
using rest config) and won't require mixing technologies when building
rest requests.

ok, but: if my understanding is correct, in order to do so I'd need to
register an XStream Converter inside XStreamPersister. For
VirtualTable and everything else so far it's been easy because they
were added directly. But the gwc integration has the "philosophy" of
being pluggable/decoupled, which makes this trickier.
First option I can think of is an extension point, say,
GeoServerConverter, that the XStreamPersister.init() method looks up
for and registers all found implementations to the XStream instance.
That is step one. But what happens if this custom gwc converted
follows the same approach than the VirtualTableConverter
(e.g. <entry name="GWC.tileLayer"><some><customXml/></some></entry>)
and then the gwc jars are removed from the classpath, including the
geoserver's gwc integration jar. Wouldn't that mapping bomb?

While most of you sleep, I'll try to find out.

Cheers,
Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime4 · February 6, 2012, 3:55pm

On Mon, Feb 6, 2012 at 4:13 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Rest assured having the tile layer configuration so close to the
layer/group is "handy". Specially because of the monolithic gwc
configuration file, which would have to be overridden as a whole
every time a layer config changes. Which makes me think that perhaps
we could get the better of both worlds by keeping the geoserver tile
layer configuration as a separate file next to the layer.xml or
layergroup config file instead, as there's no room at least on the gwc
stable branch to change its configuration subsystem to stop being
monolithic.

A gwc.xml or tilecache.xml sidecar file would be good, especially if the
contents of the file are already, or could become, large

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Gabriel_Roldan2 · February 6, 2012, 4:00pm

On Mon, Feb 6, 2012 at 12:55 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Feb 6, 2012 at 4:13 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Rest assured having the tile layer configuration so close to the
layer/group is "handy". Specially because of the monolithic gwc
configuration file, which would have to be overridden as a whole
every time a layer config changes. Which makes me think that perhaps
we could get the better of both worlds by keeping the geoserver tile
layer configuration as a separate file next to the layer.xml or
layergroup config file instead, as there's no room at least on the gwc
stable branch to change its configuration subsystem to stop being
monolithic.

A gwc.xml or tilecache.xml sidecar file would be good, especially if the
contents of the file are already, or could become, large

Yup, my inclination too. Guess it'd make things "cleaner".

So in order to finally being able of getting the UI config on _trunk
only_ I'll do that.

Cheers,
Gabriel.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · February 13, 2012, 2:14pm

On Mon, Feb 6, 2012 at 1:00 PM, Gabriel Roldan <groldan@…1501…> wrote:

On Mon, Feb 6, 2012 at 12:55 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Feb 6, 2012 at 4:13 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Rest assured having the tile layer configuration so close to the
layer/group is “handy”. Specially because of the monolithic gwc
configuration file, which would have to be overridden as a whole
every time a layer config changes. Which makes me think that perhaps
we could get the better of both worlds by keeping the geoserver tile
layer configuration as a separate file next to the layer.xml or
layergroup config file instead, as there’s no room at least on the gwc
stable branch to change its configuration subsystem to stop being
monolithic.

A gwc.xml or tilecache.xml sidecar file would be good, especially if the
contents of the file are already, or could become, large

Yup, my inclination too. Guess it’d make things “cleaner”.

So in order to finally being able of getting the UI config on trunk
only I’ll do that.

What I finally did is to keep the gwc layer configs totally separate, so less stuff to be moved around for example when a resource changes workspace etc.
So geoserver tile layer configs would be at /gwc-layers/.xml. Sounds good?

On a related note, in order to being able of saving the configuration from a layer edit page tab to someplace different than the layer/resource metadata map, some mechanism shall exist so that when hitting save both the layer is saved to the catalog, and the contributed tab can do its own save.
The following patch just does that: <https://github.com/groldan/geoserver/commit/3d262a53cef5b33e33a001aebebab65fb6bb77ee>
If no objections, I should be ready to commit.

Cheers,
Gabriel

Gabriel_Roldan2 · February 28, 2012, 4:41pm

On Mon, Feb 13, 2012 at 11:14 AM, Gabriel Roldan <groldan@anonymised.com…1501…> wrote:

On Mon, Feb 6, 2012 at 1:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

On Mon, Feb 6, 2012 at 12:55 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Feb 6, 2012 at 4:13 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Rest assured having the tile layer configuration so close to the
layer/group is “handy”. Specially because of the monolithic gwc
configuration file, which would have to be overridden as a whole
every time a layer config changes. Which makes me think that perhaps
we could get the better of both worlds by keeping the geoserver tile
layer configuration as a separate file next to the layer.xml or
layergroup config file instead, as there’s no room at least on the gwc
stable branch to change its configuration subsystem to stop being
monolithic.

A gwc.xml or tilecache.xml sidecar file would be good, especially if the
contents of the file are already, or could become, large

Yup, my inclination too. Guess it’d make things “cleaner”.

So in order to finally being able of getting the UI config on trunk
only I’ll do that.

What I finally did is to keep the gwc layer configs totally separate, so less stuff to be moved around for example when a resource changes workspace etc.
So geoserver tile layer configs would be at /gwc-layers/.xml. Sounds good?

On a related note, in order to being able of saving the configuration from a layer edit page tab to someplace different than the layer/resource metadata map, some mechanism shall exist so that when hitting save both the layer is saved to the catalog, and the contributed tab can do its own save.
The following patch just does that: <https://github.com/groldan/geoserver/commit/3d262a53cef5b33e33a001aebebab65fb6bb77ee>
If no objections, I should be ready to commit.

Hello all. Back from vacation here and catching up on a bunch of things.

Any word on this?

TIA,
Gabriel.

–
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Andrea_Aime4 · February 28, 2012, 6:27pm

On Tue, Feb 28, 2012 at 5:41 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

On a related note, in order to being able of saving the configuration from
a layer edit page tab to someplace different than the layer/resource
metadata map, some mechanism shall exist so that when hitting save both the
layer is saved to the catalog, and the contributed tab can do its own save.
The following patch just does that:
<https://github.com/groldan/geoserver/commit/3d262a53cef5b33e33a001aebebab65fb6bb77ee>
If no objections, I should be ready to commit.

Hello all. Back from vacation here and catching up on a bunch of things.

Any word on this?

The last approach you proposed looked fine to me

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------