Re: Manifest(o)s, offline reading, and EPUB+WEB

I have even stronger language to use for the AppCache spec and
implementation than that ALA article. :) We gave up on supporting web-based
offline usage via Ibis Reader (now the core Safari platform) because it was
simply unworkable in practice.

Putting aside that the implementations have all been wildly buggy, a
practical difficulty with the app cache is that it expects a 1:1
relationship between a cache manifest and a domain. If you host a single
book on a single domain, this isn't much of a scaling problem, but if you
wanted to host 100 or 100,000 books on a domain, you'd have to expire the
entire cache any time you added or removed a single title. Also, the cache
is not infinite on most platforms, and has a per-domain hard limit.

Bookish (now the Overdrive web app) does still use app cache, and gets
around this problem by creating subdomains _for every title_:

https://odcom-366d624d6b53b08a9d0a2c90b1dcea88.read.overdrive.com/
https://odcom-c2b601cb17f569fd4711e467edd142c1.read.overdrive.com/

I imagine this would be an unpopular general purpose solution.

Liza


On Mon, Jun 22, 2015 at 2:54 PM, Dave Cramer <dauwhe@gmail.com> wrote:

> We've recently spent a lot of time discussing how to make a book [1]
> readable both offline and online. As usual, this is an issue that has come
> up in the larger web world. and there is a solution already supported by
> every major browser. I'm speaking of AppCache [2], of course.
>
> At first glance, AppCache seems well-suited for books. An application
> manifest file (text-only) lists the resources used by the book, including
> CSS, images, scripts, fonts, etc.:
>
> CACHE MANIFEST
> #v3 2015-06-05
> css/mobydick.css
> metadata.json
> manifest.json
> title-page.html
> copyright.html
> introduction.html
> epigraph.html
> c001.html
> c002.html
>
>
> When you first visit a page, the files listed in the manifest are
> downloaded. The next time you visit the page, you'll get the cached
> version. This is a problem for the regular web, but could be an advantage
> for us. If you change the manifest file on the server, you will trigger an
> update of the cache.
>
> So my question is, why does everyone hate [3,sorry about the language]
> this? The cache manifest itself would be helpful for EPUB+WEB, as it gives
> us the list of files everyone seems to want, but far simpler than EPUB's
> <manifest> element.
>
> * * *
>
> To be fair, the word "manifest" is probably less overloaded than the word
> "template." Nevertheless, the "Manifest for a web application"
> specification [4] appears to be unrelated to the application manifest used
> by AppCache. Manifests for web applications are JSON files that provide
> metadata for a web app. They could provide a location and syntax for book
> metadata, and identify a starting point for the book:
>
> {
>   "name": "Moby-Dick",
>   "short_name": "Moby-Dick",
>   "icons": [{
>         "src": "icons/moby-dick-icon.webp",
>         "sizes": "64x64",
>         "type": "image/webp"
>       }],
>   "start_url": "title-page.html",
>   "display": "minimal-ui",
> }
>
> Together, these two manifests seem to meet several of EPUB+WEB's
> requirements. I'm interested in further exploring these ideas to see if
> they can be adopted or modified to meet our needs.
>
> Dave
>
>
> [1] Feel free to think "publication" every time I write "book" :)
> [2] https://html.spec.whatwg.org/multipage/browsers.html#offline
> [3] http://alistapart.com/article/application-cache-is-a-douchebag
> [4] https://w3c.github.io/manifest/
>