See also: IRC log
<trackbot> Date: 19 October 2015
<tzviya> agenda: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Oct/0039.html
scribenick mgylling
<tzviya> scribe: mgylling
tzviya: new member introduction: Nick Barreto
nickbarreto: I am the cofounder of Canelo, a digital publisher in the UK.
… been working with ebooks mostly for large publishers, one of the the things we care about is doing digital publishing not as an afterthought but bringing it to the forefront
<tzviya> http://www.w3.org/2015/10/12-dpub-minutes.html
Tzviya: We are happy to have you
tzviya: any comments?
Luc: I was present but I am not on the list
<Karen> PWP
Jake: I work for Google Chrome in the UK, one of the co-editors of the Service Workers spec
<tzviya> http://www.w3.org/TR/service-workers/
… what do you want to know from me? An overview?
… SW itself is just a javascript runtime that can operate on a separate thread. Key difference in life cycle is that it can spin up without the existence of pages on the origin
… the starting point for the web becomes the SW rather than the page. One of the key features is offline because you get a fetch event for every request the page makes, so you can create an offline experience by listening for fetch events
… you get to choose what to do, the default being nothing, but you can create a response, a string or blob and send that back
… or you can fetch things from named caches, from IndexedDB
… gold standard of this type of app development is “offline first”, create the offline experience before even attempting to go to the network, seeing the network as progressive enhancement
… the aim is to ship stuff from the caches as quickly as possible, and then go to the network
… lots of user experience we are trying to figure out now, but the SW specification doesn't make any of these decision
<tzviya> http://www.w3.org/TR/2015/WD-pwp-20151015/#arch
tzviya: summary I hope fits with the PWP document we have published
… historically most digital publications are an offline experience, but we are looking to bridge online and offline for the user as a seamless experience
Jake: haven’t had time to read the PWP doc yet
dauwhe: I played around with this a little bit, one of the things we are thinking about is how to we make ebooks first class citizens on the web. How can we make a good reading experience in browsers without the need for dedicated reading systems? Basic functionality we want to achieve on the web, and reading offline is one example of the functionality we need
… using SW was step on, I am curious about what more could we do? If the SW intercepts a URL request, can it redirect?
Jake: when the user requests a particular URL you can respond with another. We are also working on streams
… you could use a SW to build an ebook reader which would request one of these ebook formats on the fly and rewrite it to HTML, even streaming if the ebook format supports streaming
dauwhe: in EPUB we are looking at an unzipped format
Jake: the problem with the zip format is that the directory is at the end of the file
dauwhe: Readium uses byte ranges I think for zip
ivan: There is work going on on more streamable web packaging, heard gossip that all this was pending, since SW would take care of it. Do you know about this?
<dauwhe> http://w3ctag.github.io/packaging-on-the-web/
Jake: a while ago I heard about this, personally I am not sure what the benefits are, we have a platform where we can store things separately. I guess that's why they are waiting for SW. We are very much subscribed to the extensible web manifesto with this, going as low as we can.
… but something like recieving a zip format and searching inside is one thing SW can do
ivan: that was the main reason they were looking at the packaging stuff, the other questions I have is more on the practical side: I looked at the spec, I am not a webapp developer and I could not understand it. Is there work going on to sort of popularize the whole thing to make it more palatable?
Jake: I symphatize, as a web developer even I find the specs impenetrable. At the moment I am working on an offline course through Udacity [?] and free
… hope to release that in December, hope to convert it to a series of articles as well
<tzviya> https://jakearchibald.com/ is also helpful
Ivan: it is part of Chrome already, works in Firefox too, what about the other two?
Jake: Firefox will be fully implemented soon. Microsoft has given thumbs up, but has not started work on it. The big question everyone asks is about iOS Safari. We are not sure about the progress there. They are now taking part in the F2F meetings which is a positive.
… but there is no date for that
BillK: we should be careful to avoid the linear eBook paradigm, not just a matter of unpacking an navigating linearly
Jake: F2F next week we will try to solve how to deal with range requests
… can you build a cached item progressively using multiple requests
… the web doesn't really need packaged formats, range requests are a preferred model
… I took a stab at making an offline version of Wikipedia. That model worked really well, you might not cache the whole thing offline
dauwhe: I just wanted to partly answer Ivan's question about the difficulty of the spec. There were enough tutorials out there that I could create my sample using that.
Jake: one of the things on our TODO list for next year is a shim for SW that will read AppCache manifests, to provide a path for people who just wants to read a list of files
… we want to sit back and see what the common things are
DanielWeck: I am a developer at Readium, OSS implementation of EPUB 3 Reading Systems, native apps and web-based readers inc a Chrome app.
… Readium will read an EPUB that is exploded on the server side. Unzip onto a filesystem on a server, and Readium can fetch the data from the unpacked file system. The challenges we face is when we try to fetch data in the zipped form.
… what we have to do extract the contents of the EPUB on the fly, we can do that using a ZIP library and using byte-range requests, however the main caveat is that we have to preprocess, parse the content recursively and populate that tree with blob URIs which creates problems in a WebView. But SW solves that problem since we can intercept requests
… using syntactic conventions we can capture that via the fetch event and return responses that will emit a payload
… this could be extended to media files, but we haven't implemented that yet
… Our implementation does not use SW for caching, only for request intercepts
… caveats: the domain scope of the SW implementation has to be hosted under a particular location on the filesystem on the serverside
Jake: that is true but you can override that with a header
DanielWeck: we’ve got same-origin requirements on EPUB content, is that inflexible?
Jake. Yeah. The whole reason for the same-origin constraints is […] security and privacy
DanielWeck: requirements for https. I didn't face any issues there, but you have to use https?
Jake: Yes, we tried to avoid but couldn't find a way to do it
… if you are on a router that is not yours, you don't know it is safe, if you access BBC news, a man in the middle can intercept that, which is bad. But it gets worse if the register a service worker which can intercept and live beyond the session lifetime. That is possible with AppCache, which is really bad.
DanielWeck: the fact that the SW is by design [???] we don't want to wait for SW registration to finish. The need to reload the page […]
Jake: I would have some kind of, if navigator.serviceworker.controller is undefined, show some kind of loading screen. You dont need to refresh the page, you can call client.claim()
<DanielWeck> delayed Service Worker registration (first-time reload), general Worker restrictions (no XmlHTTPRequest), browser support
tzviya: Daniel: sounds like you have many questions for Jake. Maybe we can solve this via email.
<astearns> what's the best public list for service worker feedback/questions?
… at TPAC we cant do a formal meeting since our groups are meeting on the same day, but informal discussions we hope can happen
ivan: the work we do in this interest group might rely a lot on Service Workers moving forward, in the future we may need probably several times help from you
Jake: thats what I am here for
tzviya: Daniel maybe we can arrange for you
to call in
... thanks Jake!
deborah: I believe we are just doing a brief update, we had been given a request from PF to tell us if this is what you want, we made some modifications which are here:
<dkaplan3> http://w3c.github.io/dpub-accessibility/extended-description-analysis.html
<dkaplan3> http://w3c.github.io/dpub-accessibility/extended-description-analysis.html#use-cases
most changes are in the use cases section, where we talk about the possible use cases for ED. We have stepped back from pushing a particular term, and instead focus on the behavior we need
… this is a list of functionality the Digital Publishing needs for accessibility purposes
ivan: shoot
deborah: then that's what we will do
… extra thanks to Mia Lipner from Pearson
tzviya: and many thanks to Deborah too
karen: thanks to tzviya and nick we started to iterate and here’s a draft
… to contextualize what this PWP is and what it means. We are hoping that you could take a look
… scroll down to communications planning. Still needs some links and things. After our discussion last week, we wanted feedback to see if this communication makes sense, for W3C, IDPF, DBW, PW, etc
ivan: whats the timing? We have published but we haven't done any outreach
karen: preferred timing would be next week
<Karen> Not yet, no
… lets wait with tweeting etc until we agree with the messaging
tzviya: five minutes left
… next week no meeting since we are at TPAC
… in the following week we will have shifted daylight savings. We will stay with the local times and shift the UTC.
<dauwhe> werewolf time!
tzviya: thanks everyone