Ticket #44 (new task)

Opened 6 years ago

Last modified 6 years ago

manage remote image services

Reported by: tschaub Owned by:
Priority: major Milestone:
Component: Styler Keywords:
Cc: Total Hours: 0.0
Estimated Hours: 0

Description

This ticket is intended to start discussion on what will be required to implement the "Images From" combo functionality and the functionality implied by the "add image set" item in that menu.

Ticket #43 describes an image service where GeoServer manages local image resources (lets users create new images, get a list of images, delete images, etc).

If remote GeoServer has the same image manager plugin (or however implemented), the design proposal implies the the user could browse images from that remote GeoServer. From the perspective of the client, all requests of this type come from the same server. So, a proxy can be set up that allows remote image resources to be managed.

It is bad practice, however, to ship around software that sets up an open proxy on the web. So, the proxy can limit requests in a number of ways: by a list of allowed hosts, or by content type (or any other information in requests). Since the image manager service speaks in common content types (form encoding, image types, etc), it doesn't make sense to have the proxy limited by content type. So, the proxy should limit based on a list of allowed hosts.

If the proxy limits based on hosts, something has to manage the list of allowed hosts. (An alternative is to have something special about GeoServer to allow one GeoServer to proxy all other GeoServers.) If the server is going to maintain a list of allowed hosts for these image services, then it implies that the "Add image set..." option in the menu on the design proposal lets the user put in the URL for a remote service and that URL is persisted by the server.

If this route is chosen, we need to discuss how the client makes requests for a list of images on a remote server. One option is to create some sort of generic proxy for GeoServer.

Then the client could get a list of GeoServers that the local one is configured to proxy.

GET /geoserver/proxy/hosts

Returns a list of remote GeoServers that can be proxied. An open question is how the client knows what capabilities those GeoServers provide.

If the client assumes that all GeoServers are equally capable (and configured), getting a the list of remote image servers (the list shown in the "Images from: " drop-down in the design proposal) is as easy as getting a list of allowed hosts from the proxy.

If the client cannot assume that all hosts allowed by the proxy offer the same capabilities, then compiling the list of remote image sets is more complicated.

An alternative to a generic proxy would be something specific to this type of image server. So, GeoServer could manage a specific list of remote image servers.

Change History

Changed 6 years ago by tschaub

The "Add image" and "Remove selected" also imply that the user can modify remote image sets. Assuming not all servers want all clients modifying their image resources, servers also need to advertise something about permissions. This should probably be part of a larger discussion on authorization related to editing/viewing remote resources (OAuth comes to mind).

Note: See TracTickets for help on using tickets.