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

On Tue, 2015-06-23 at 14:48 +0000, Bill Kasdorf wrote:
> I probably shouldn't say this but as a dyed-in-the-wool English 
> major I can't help myself.
> 
> George Eliot wrote Middlemarch.

She did, well spotted :-)

In practice an ISBN or edition identifier is more likely to be used 
there.

But, again, I'm not promoting AppCache as it stands, but making sure 
that "you have to register millions of hosts" wasn't seen as a show-
stopper.

Liam

> 
> I may not be the most expert code jockey on this IG, but I know my 
> literature. ;-)
> 
> --Bill K
> 
> -----Original Message-----
> From: Liam R. E. Quin [mailto:liam@w3.org]
> Sent: Monday, June 22, 2015 10:59 PM
> To: Brady Duga
> Cc: Liza Daly; Dave Cramer; W3C Digital Publishing IG
> Subject: Re: Manifest(o)s, offline reading, and EPUB+WEB
> 
> 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/
> > > > > 
> > > 
> > > 
>

Received on Tuesday, 23 June 2015 15:24:57 UTC