- From: Liam R. E. Quin <liam@w3.org>
- Date: Mon, 22 Jun 2015 22:58:51 -0400
- To: Brady Duga <duga@google.com>
- Cc: Liza Daly <liza@safaribooksonline.com>, Dave Cramer <dauwhe@gmail.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
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 02:58:56 UTC