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

I expect it will be unlikely I can get permission to create 5 million
google.com subdomains. I don't think this scales very well. I don't know
much about appcache - can the resources be on different domains than the
manifest? Not all content for a single book is necessarily served from the
same domain.

On Mon, Jun 22, 2015 at 3:10 PM Liam R. E. Quin <liam@w3.org> wrote:

> On Mon, 2015-06-22 at 15:14 -0400, Liza Daly wrote:
> > 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.
>
> Why would it be unpopular? It was certainly my first thought on how to
> get round the limitations of AppCache. Subdomains are cheap and can
> easily be turned into a low-overhead search on a Web server.
>
> It does mean you have to have cooperation from your web server people,
> though, if only to install the search engine.
>
> Invalidating the entire cache for a book might be a pain, though, if
> the book is, say, a gigabyte in total size.
>
> This also maybe provides a mechanism to link between books.
>
> Liam
>
> >
> > 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/
> > >
>
>