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

> On 23 Jun 2015, at 10:50 , Koji Ishii <kojiishi@gmail.com> wrote:
> 
> You might want to take a look at Service Worker.

Indeed, that was my first thought, too.

First of all, I believe that the basic message of Dave is absolutely right: *something like* manifest and AppCache is the mechanism we would have to have for EPUB+WEB, ie, for offline/online publications. My *limited* understanding[1] of Service Workers is that it provides an API to handle cache-like features in a programmable way (and also involving true multithreaded operations, which is a plus). Ie, it is not the full automatism of AppCache, but it is possible to build a decent caching behaviour for, e.g., e-publications if one has clever WebApp developers around.

Maybe the EPUB+WEB work (in the new IG if it gets chartered) will have to develop some sort of a proof-of-concept reading system on top of Service Workers...

Ivan

[1] https://github.com/w3c/epubweb/wiki/Notes-on-Web-and-Service-Workers

> 
> /koji
> 
> On Jun 23, 2015 11:59 AM, "Liam R. E. Quin" <liam@w3.org> wrote:
> On Mon, 2015-06-22 at 23:00 +0000, Brady Duga wrote:
> > 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.
> 
> You actually only need to create one subdomain, e.g.
>     read.google.com
> Then, allow *.read.google.com to resolve to read.google.com.
> 
> Then people would use e.g. middlemarch.thomas-hardy.read.google.com
> and that would match *.read.google.com, go to the right place, and
> could be passed to a database seach (say).
> 
> I'm not trying to promote this - AppCache isn't really designed for
> this use case and might or might not work well out of the box - but
> I'm also not trying to shoot it down.
> 
> >  Idon'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.
> 
> The AppCache spec wants everything on the same domain. You can point
> outside but other things won't be pre-fetched for offline use, as I
> understand it.
> 
> Liam
> 
> >
> > 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/
> > > > >
> > >
> > >
> 


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704