Skip to content

GSIP 178

Nuno Oliveira edited this page Oct 4, 2019 · 13 revisions

GSIP 178 - Extra metadata for single and opaque layers groups (enabled and advertised)

Overview

The goal of this improvement is to add the enabled and advertised options that are currently only available for single layers:

Having those options checked will have the same impact that they have on single layers:

  • Enabled: a layer group that is not enabled won’t be available to any kind of request, it will just show up in the configuration (and in REST config), layer groups will be enabled by default;
  • Advertised: a layer group is advertised by default, a non-advertised layer group will be available in all data access requests (for example, WMS GetMap, WMS GetFeature) but won’t appear in any capabilities document or in the layer preview.

Proposed By

  • Nuno Olivera
  • Imran Rajjad

Assigned to Release

This proposal is for GeoServer 2.17.0 and backport to 2.16.1.

State

  • Under Discussion
  • In Progress
  • Completed
  • Rejected
  • Deferred

Motivation

This feature will allow to enable/disable visibility and advertisement of layer groups (single and opaque mode) just like a a normal single layer. This options are particularly relevant when creating single layers.

Proposal

Currently

Currently the information necessary to handle the advertised and enabled behavior is hold by the the ResourceInfo interface which requires implementation of the following methods:

  • boolean enabled();
  • void setEnabled(boolean enabled);
  • boolean isAdvertised();
  • void setAdvertised(boolean advertised);

This methods are also replicated in LayerInfo interface.

Making this properties available for will require changes on existing interfaces:

                               CatalogInfo
                                    |
                                    |
     -------------------------------------------------------------------
     |                                                                 |
     |                                                                 |
   ResourceInfo                                                 PublishedInfo 
                                                                       |
                                                                       |
                                                                 LayerGroupInfo                                                                                                          

Is worth mentioning that the advertised behavior is handled by AdvertisedCatalog and the enable behavior is mostly handled by DisabledResourceFilter.

Proposed Changes

Both advertised and enable behavior will be added to the PublishedInfo interface, making them available for both layers and layers groups.

Using the two new attributes

For Advertised: changes in AdvertisedCatalogat AdvertisedCatalog.securityFilter

For Enabled: provide an implementation of hideLayerGroup(LayerGroupInfo layerGroup) inside DisabledResourceFilter

For WEB GUI: checkbox will be added and linked to underlying model at LayerGroupEditPage.LayerGroupTab.initUI

Backwards Compatibility

We don't foreseen any backwards compatibility issue:

  • the existing concrete implementations will not be changed, so the serialization compatibility will be maintained
  • default methods will be provided in the changed interfaces

Feedback

Taking into account Andrea feedback:

Sorry I could not participate much to the original discussion, the proposal was sent during FOSS4G, and with the build server still storming the devel list (I see I added a few comments, but I did not understand the proposal well)

For this one, and within the limits of the current implementation (as per PR) I have to cast a -1. The current implementation changes CatalogInfo with two new bean properties, some of them are not making sense for all cases, for example, advertised is for OGC services (the REST configuration API shows all items the admin is allowed to see) , stores are not visible, workspaces not directly, barring any change in the general GeoServer behavior, advertised will never make sense for those.

The default setter implementations in CatalogInfo does nothing, breaking the bean behavior pattern (a setter has to change the value of the property).

If the getters are to stay there, at the very minimum:

  • remove the setters default implementation
  • clearly advertise the enabled/advertised property can be read only (it's not common for catalog objects, it will surprise developers and REST API users alike)
  • make sure the properties do not end up showing in the REST API for objects that have it read only, or change the REST API documentation stating
  • in which objects the values cannot be changed

So we refactor the PR to put the properties in PublishedInfo, this seems indeed to fit better GeoServer design.

Before the mailing list discussion the following two approaches where proposed:

Option 1: Make the required properties (enabled and advertised) part of LayerGroupInfo just like keywords

Option 2: Move the properties (enabled and advertised) up into CatalogInfo so that both branches can provide implementations of the required methods

Voting

Project Steering Committee:

  • Alessio Fabiani: +1
  • Andrea Aime: -1
  • Brad Hards:
  • Ian Turton: -0
  • Jody Garnett: +1
  • Jukka Rahkonen:
  • Kevin Smith:
  • Simone Giannecchini: +1

Links

Clone this wiki locally