Added content provider custom URL

Bug #1423332 reported by Jeff Davis on 2015-02-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

It's currently possible to include locally hosted content in the TPAC, as described here:

However, this does not trivially scale to multiple web nodes (the same content needs to be accessible on each EG server's filesystem). It's also problematic because EG always tries to read a local file before falling back to any remote provider - so if content is hosted on an NFS share and the NFS share goes away, we block on checking the file and the page will not be rendered.

Instead, we propose an added content provider that allows the programmatic construction of custom URLs for various added content services. The configuration should take a base URL and a number of variables that can be substituted, and indicate which types/formats a URL is valid for to allow for different services for different types of content.

Any of the following forms would be valid:

http://catalog/opac/extras/ac/{type}/{format}/r/{recordid} - this is the current supported form for locally hosted content{type}/{format}/r/{recordid}
https://user:<email address hidden>/isbn-image/{isbn13}/{format}

Open questions:

1. What should the syntax for variables be?
2. What variables should be available? For example, do we want to be able to pass values from specified MARC fields, e.g. a local identifier for the image in a 9XX tag?
3. What happens if there is no content (404, 500, or other HTTP errors) at the URL?
4. Where should the configuration live: config.tt2, opensrf.xml, in the database...? I think config.tt2 is the obvious choice, but perhaps there are arguments against this.

Changed in evergreen:
importance: Undecided → Wishlist
tags: added: addedcontent opac
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers