Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

Well, since we're all sharing today, let me share the perspective from the
Readium side.

When we started thinking about Readium-2 about a year and a half ago, we
looked at what works and what doesn't work so well in Readium-1.
We quickly identified that:

   - the server/client model is the only good solution for native apps as
   well, and that even for EPUB, we're better off using an HTTP server
   - that Readium-1 lacked a good manifest format, we needed something more
   abstract that could work with any publication (not just EPUB) and that
   would be the bridge between the server component (the one that parses
   packaged publications and expose them using HTTP) and the client component
   (pretty much what we've been talking about in the previous thread, with all
   the publication specific affordances)

We extended and improved previous work that was started during the EPUB 3.1
BFF effort and very quickly built prototypes that worked very well and
unified our vision as well. Thanks to this manifest we could easily:

   - build native apps for reading publications
   - build Web apps and browser extensions for reading as well
   - stream remote publications in a native app or a web app (the business
   model or use case for that is IMO very obvious as well)

As we continued working on this manifest, we also discovered that:

   - our manifest is also a good fit for audiobooks and made it easy to
   support streaming or caching for those (there's a desperate need to
   standardize audiobooks)
   - it's a good fit for comics as well, which a WG within EDRLab is now
   working on
   - it's also a good way of extending EPUB, since we can easily embed our
   manifest at a well-known location (manifest.json) and rely on it (instead
   of an OPF) for specialized use cases (like comics, where EPUB and FXL are
   super limited and get in the way of the reading system)
   - the hypermedia nature of its design also made it a good fit for a new
   revision of OPDS (meant to distribute publications and browse/search a
   catalog) as well as a new generation of OPDS parsers

One thing that we never focused on where publications primarily distributed
on the Web, because we didn't had a use case for them.

I think that the whole "EPUB vs the Web" thing is misguided. Instead of
long discussions about polyfills we should focus on:

   - affordances ("what we want to build in terms of UX")
   - use cases ("why we're working on these specifications")

As we've seen with Readium-2 and the Readium Web Publication Manifest,
sometime we accidentally find good solutions to problems that we never even
considered in the first place.

Best,
Hadrien