...
The features are discussed below.
...
OPDS is the standard at the core of SimplyE. An OPDS feed is a list of books. Each entry in the feed contains metadata for a book (title, author, etc.) and instructions on how to get a copy of the book.
One OPDS feed can link to another, just like one HTML page can link to another. There are all kinds of reasons why one OPDS feed might link to another, but these are the two most important, and should give you the general idea:
...
in
...
OPDS as user interface
When the SimplyE mobile app is pointed at an OPDS server, the links between OPDS feeds determine the graphical user interface shown to SimplyE, just as the links between HTML pages become the user interface of a website. There are two main features of OPDS which elevate it past just a big scrolling list of books:
- Grouped feeds, which create a Netflix-style browsing interface.
- Navigation feeds, which let a reader drill down into categories and subcategories of books.
(Note that the SimplyE mobile app doesn't actually support navigation feeds yet. Grouped feeds offer a nicer version of the same functionality, but it's more work on your end.)
If your OPDS feed is intended for distributing books through other institutions, rather than for direct consumption by the SimplyE App, you should probably just create a simple paginated list of books with the newest books at the top.
Static generation
In most cases, it's preferable to generate your OPDS feeds statically ahead of time. As your collection becomes more complicated, it may be more practical to generate OPDS feeds as needed and cache them.
| Info | ||
|---|---|---|
| ||
Common Issues with Feeds not working with the Circulation Manager
|
| Info | ||
|---|---|---|
| ||
Classification the CM can use to organize and process works into the catalog The following should be brought in if used for classifying works or used when constructing OPDS feeds intended to be used in SimplyE. category term="Children" scheme="http://schema.org/audience" label="Children"/> |
...
following documents
...
An Authentication For OPDS document explains what it takes for a person to actually get access to your collection. You can advertise three authentication techniques in your Authentication for OPDS document:
- Anonymous access (no authentication)
- HTTP Basic Auth (username/password)
- OAuth client credentials grant (used only by the token service below)
We also support a wrapper around OAuth's authorization code grant. For a working example, see Clever login in the Open Ebooks app. However, the situation there is so unusual that we don't want to give general advice. If you authenticate your users with an OAuth authorization code grant, contact us and we'll figure out how to work you into this strategy.
Collection metadata extensions (e.g. Library Registry) The library registry and the SimplyE mobile client also recognize a large number of extensions to Authentication For OPDS which let you specify detailed information about your collection: things like a description, the audiences and geographic locations you serve, the estimated number of titles you have in various languages, and even the color scheme to use when displaying your collection.
The automatic library registration process (not yet designed) takes your Authentication For OPDS document as its input. These extensions contain the information it needs–description, geographic locations, and so on–to put your OPDS server in the library registry and help people find it.
...
Even if your OPDS server allows anonymous access, you can't join the SimplyE library registry without an Authentication For OPDS document. There are two reasons for this. First, you need to explicitly state that your OPDS server allows anonymous access, and the Authentication For OPDS document is the place to do that. Second, the library registry needs all that extension information–your colleciton's description, audiences and languages, and so on–and that stuff goes in the Authentication for OPDS document.
Static generation In most cases the Authentication For OPDS document can be a static document. You only need to regenerate it if something about your server's code or configuration changes.
...
This is not technically required, but unless your collection is very small, readers will expect to be able to search it. If you don't deal directly with readers, then you probably don't need this feature.
Opensearch You can implement your search service however you want. The SimplyE Collection implements it with an Amazon Lambda service; the circulation manager uses a wrapper around an ElasticSearch. The only restrictions are:
- Your search service must be advertised with an OpenSearch document.
- Your search service must serve its search results in the form of an OPDS feed.
You advertise your search service by linking to the OpenSearch document from your OPDS feeds. Here's an example from The SimplyE collection:<link href="https://instantclassics.librarysimplified.org/search" type="application/opensearchdescription+xml" rel="search"/>
Fetch that document and you'll see that it explains how to construct a URL that performs a search:<?xml version="1.0" encoding="UTF-8"?> <OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/"> <ShortName>Search</ShortName> <Description>Search</Description> <Tags></Tags> <Url type="application/atom+xml;profile=opds-catalog" template="https://instantclassics.librarysimplified.org/search?q={searchTerms}"/> </OpenSearchDescription>
Build a search URL, send a GET request to it, and you'll get an OPDS Feed of search results.
...
Unless you allow anonymous access to your collection, you'll need to have some kind of software that guards access to your books, and possibly even to the OPDS feeds themselves. There are a variety of ways of doing this, but most of the time this means implementing HTTP Basic Auth and looking up credentials in some kind of data store.
Token service The token service is only necessary in one case:
- You are a distributor who sells access to your collection to libraries.
- But you don't want the libraries downloading your books, rehosting them, and serving them to their patrons.
- Instead, you want the library patrons to come to you whenever they want to download a book.
To see the problem here, consider a specific case. I come to your site and say "I'm a patron of library X; give me this book." You've agreed to hand out copies of this book to patrons of library X, but how do you know I'm really a patron of library X? Am I supposed to show you my library card? How do you know it's legitimate?
When you set up the contract with library X, you sent out a username and password for that library to use when accessing your OPDS server. If I, the patron, had that username and password, I could access your OPDS server and download the book. But I shouldn't be given that username and password. I'm not library X, I'm just a patron of library X.
Library X shouldn't have to give out its credentials to every patron who asks. It should be able to delegate its authority to a patron for purposes of downloading a specific book from your server. This is what bearer token propagation is for, and it's covered in a separate document.