We need to be able to configure the application to support different media types in different manners. The current solution we are considering is to have each media type exist in a config file with a class of support. The problem deserves some exploration. There are few simultaneous use cases we are trying to solve:

1. Open eBooks would like to not show books in the list view if they don't have the AxisNow read online format.
2. In the non Open eBooks world, if a book doesn't have a supported format, it should probably still be shown and borrowable, but the user should be told beforehand that they will have to use SimplyE in order to read it. After borrowing, they should simply be directed with UI to read it in SimplyE.
3. Open eBooks would like to have an action present on the book list view to either "Borrow" or "Read Online". This is possible in their case, because they would only support a single format (AxisNow), so we wouldn't have to show multiple buttons for the different formats.
4. Lyrasis would like to direct users to read a book in SimplyE as their primary form of fulfillment. However, they would like to have other download and read online options available.
5. In the non-openebooks world, if a book has an Adobe encrypted Epub, opening it on desktop will lock the user to reading it only in that one app. This should either be explained in UI, or the app should be able to be run without support for displaying that media type. 

Questions - 

• In use case #1 - what would happen if a user has both mobile and web apps? Then they can borrow a book on mobile that isn't even shown anywhere on web... would we show it in their loans page and not in their collection page?

Proposed Solution

We configure CPW to be able to take a "media support config file" as part of the env at startup. This file tells CPW how to handle different media types. There would be four classes of support:

• Preferred - if this media type is available, it should be the default fulfillment method. This also indicates that this fulfillment method should be presented as the single option on a list view.
• Allowed - this media type can be shown, but the app will default to directing the user to read the book in SimplyE instead. 
• Unsupported - This media type isn't shown as a fulfillment option, but books that only have this media type still show up in list views and search results
• Hidden - This media type isn't shown as a fulfillment option, and books that only have this media type will be hidden from the list view.

This way, Open eBooks can simply list everything except AxisNow as "Hidden", and AxisNow as "Preferred". Lyrasis and others, meanwhile, can add more fine grained control, and have the option to mark some type as "Preferred" in the future, for example when a web reader is integrated and accessible by them.

A naive version of the config file would map from the direct media type to the support class. However, that fails to take into account that different combinations of indirection and concrete media can also lead to different support classes. For example, a simple Epub may be Allowed, but an Adobe Encrypted Epub might be Unsupported. Therefore, we actually need to map from the combination of indirect and direct type to a support class. This config might therefore become quite large, though it would then be simple to change how the app supports any given case.

Unknowns -

• How do we handle multiple "Preferred" media types? Maybe there should only be one allowed in the config file? This might not suite the case where an instance wants any read online format to be preferred, regardless of whether it's Overdrive or internal Webpub Viewer. If we wanted to support multiple preferred types, we would need to them to be prioritized in the config.
• Do we need to configure the labels for the callouts on each of these? For example, right now it is hardcoded that AxisNow buttons say "Read Online". Do we need them to simply say "Read"? If that is the case, the label would need to be configurable as well, because "Read" wouldn't make sense in the context of multiple options. 

Other Considerations

We are now adding a second config file that CPW will ingest. It probably makes sense to combine the current config file and this media support config file into one JSON file. The current config file maps from library short name to catalog root url for running with multiple libraries. If we were to do this, it would be best to get everyone to switch to the new config file format when we finally release version 3 (which includes a lot of other work). This way we don't have to add backwards support for the old config file format.