Output an OPDS 2.0 feed listing publications

[HadrienGardeur]

While the current version of the Go streamer is focused on parsing and serving a single publication, the use case for both the Go and node.js/Typescript versions of the streamer might be primarily on the server side.

To better adapt to such use cases, we should do the following:

• by default, parse and keep in memory all publications stored in publications/
• provide an OPDS 2.0 feed for these publications at /publications.json

OPDS 2.0 is not truly a thing yet, aside from a few experiments on Gist.

But to reach a point where we're comfortable writing a specification for OPDS 2.0, we need to experiment and this is the perfect opportunity to do it.

Here are a few ground rules:

• OPDS 2.0 will be based on the same abstract model as the Readium Web Publication Manifest, which means collections, Link Object, links and metadata
• the media type for OPDS 2.0 is application/opds+json
• there won't be a difference between acquisition and navigation feeds in OPDS 2.0, all feeds contain a number of collections
• there will be three core collection roles: publications (equivalent of an acquisition feed), navigation and groups (to replace rel="collection" and aggregate publications together in a single feed)
• the output that the streamer will provide is a very basic OPDS 2.0 feed where all publications are listed in a publications collection
• this collection won't contain the full content of a Readium Web Publication (we'll only include metadata, links and a new images collection that contains one or more different covers)

Here's a very basic example of what the output will look like:

{
  "@context": "http://opds-spec.org/opds.jsonld",

  "metadata": {
    "@type": "http://schema.org/DataFeed",
    "title": "All Publications",
    "numberOfItems": 1
  },

  "links": [
    {"rel": "self", "href": "http://example.org/publications.json", "type": "application/opds+json"}
  ],

  "publications": [
    {
      "metadata": {
        "@type": "http://schema.org/Book",
        "title": "Moby-Dick",
        "author": "Herman Melville",
        "identifier": "urn:isbn:978031600000X",
        "language": "en",
        "modified": "2015-09-29T17:00:00Z"
      },
      "links": [
        {"rel": "self", "href": "http://example.org/manifest.json", "type": "application/webpub+json"},
      ],     
      "images": [
        {"href": "http://example.org/cover.jpg", "type": "image/jpeg", "height": 600, "width": 400},
      ]
    }
  ]
}

[HadrienGardeur]

This is also relevant for the node.js/Typescript version cc @danielweck

I'm also interested in receiving feedback about the output from @aslagle or @leonardr

A few things that are different in OPDS 2.0 with the current proposal:

• the new model allows multiple collections, which was a major limitation with Atom in OPDS 1.0
• through JSON-LD, we'll get an RDF representation of what we're describing in each feed
• images are now a collection instead of just a link with a specific rel value, this is primarily meant to support responsive images (multiple formats and size listed, the client can then select the best fit like in HTML5)
• groups are now an explicit element, based on a new collection role (client won't have to guess anymore, based on link@rel="collection")
• I don't think that an acquisition link should be a requirement if a publication can also be accessed directly (which is the case here, since you can access the manifest for a publication and access the publication that way), but we're not dropping the concept either