Dynamic selector for added content provider

[Jeff Davis]

(See also bug 1423332.)

At present, added content configuration is performed on a system-wide level in opensrf.xml. In consortial environments, this precludes the ability for specialized libraries to have certain added content unique to their collections.

We propose a new added content module that allows selection of added content provider based on the library or the individual bib record. This dynamic selector would be the basic added content provider specified in opensrf.xml, so the basic design of the added content module would not change - you can still specify a single provider for all libraries.

Here are some possible approaches. We're not tied to any of them, just indicating ways of implementing this.

Example #1: TPAC-level config:

- in opensrf.xml:

<added_content>
    <module>OpenILS::WWW::AddedContent::DynamicSelector</module>
   <mode>tpac</mode>
</added_content>

- in config.tt2:

added_content.module = 'ContentCafe';
added_content.base_url = 'http://contentcafe2.btol.com/ContentCafe/';
added_content.username = 'xxxx';
added_content.password = '1234';
...

Example #2: Org unit-level config, with available providers listed in opensrf.xml and selected via YAOUS:

- in opensrf.xml:

<added_content>
    <module>OpenILS::WWW::AddedContent::DynamicSelector</module>
   <mode>org_unit</mode>
    <content_providers>
        <added_content id="1">
                    <module>OpenILS::WWW::AddedContent::CustomURL</module>
                    ...
        </added_content>
        <added_content id="2">
                    <module>OpenILS::WWW::AddedContent::ContentCafe</module>
                    ...
       </added_content>
     </content_providers>
</added_content>

- in the database:

-- value points to the added_content id
INSERT INTO actor.org_unit_setting (org_unit, name, value)
VALUES
    (1, 'added_content_provider', 1),
    (2, 'added_content_provider', 2);

Example #3: Bib-level config, with a prioritized list of potential content providers per record as specified in the db:

- in opensrf.xml:

<added_content>
    <module>OpenILS::WWW::AddedContent::DynamicSelector</module>
   <mode>bib</mode>
</added_content>

- in the database:

CREATE TABLE config.added_content_provider (
  id SERIAL,
  module TEXT
);
CREATE TABLE config.added_content_provider_setting (
  id SERIAL,
  provider INT REFERENCES config.added_content_provider,
  setting TEXT,
  value TEXT
);
CREATE TABLE biblio.added_content_provider_map (
  id SERIAL,
  record INT REFERENCES biblio.record_entry,
  provider INT REFERENCES config.added_content_provider,
  priority INT NOT NULL DEFAULT 1,
  UNIQUE (record, provider)
);

Open questions:
1. At what level should the selector be configurable: per org unit, per bib record, per TPAC skin, or some combination thereof? (Without a redesign, added content cannot be per-volume or per-copy.)
2. Should there be fall-through to allow multiple providers to potentially answer for the same record, if the first returns no results?
3. If the dynamic selector is used, where does the configuration for each added content provider live?
4. Do we allow multiple instances of the same added content provider with different parameters - e.g. two different user accounts for Content Cafe?

[Mike Rylander (mrylander)]

I would strongly prefer this go into the database, obviating the opensrf.xml bits altogether. Your third example is very nearly there, but is bib-specific. That could certainly be generalized to support general more cases, though.

If you agree, and start down that road, I would recommend making your config.added_content_provider table a reusable primitive, and allow multiple owners to map settings to their chosen provider.