W3C home > Mailing lists > Public > public-digipub-ig@w3.org > November 2015

Re: Offline-enabled online book & ebook reader

From: Brady Duga <duga@google.com>
Date: Mon, 9 Nov 2015 07:57:10 -0800
Message-ID: <CAH_p_eUU7D_DKXAwWw+XKCwWW0oGeGD7REyWqN32xMj=WSNZtg@mail.gmail.com>
To: Bill Kasdorf <bkasdorf@apexcovantage.com>
Cc: Ivan Herman <ivan@w3.org>, Jake Archibald <jakearchibald@google.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>, Tzviya Siegman <tsiegman@wiley.com>
+1. I think a manifest is incredibly important for correctly and
efficiently gathering all the required resources. Trying to determine which
resources need to be downloaded without that, especially in the presence of
scripting, would range from difficult to impossible. It is also generally
easier to identify which resources are part of a publication than it is to
identify which aren't. The former can just be a list, the latter may need
to be a complex set of rules or a simpler set of rules with additional
restrictions imposed on the publication.

On Mon, Nov 9, 2015 at 7:14 AM, Bill Kasdorf <bkasdorf@apexcovantage.com>
wrote:

> Glad to hear your ["probable"] support for a manifest. I think that is
> really essential for a PWP. And although I will be happy to be corrected if
> I'm wrong, I don't think a spine or <nav> is sufficient, since there can be
> so many resources (of so many types) that are only indirectly discoverable
> through them.—Bill K
>
>
>
> *From:* Ivan Herman [mailto:ivan@w3.org]
> *Sent:* Monday, November 09, 2015 4:32 AM
> *To:* Jake Archibald
> *Cc:* W3C Digital Publishing IG; Tzviya Siegman
> *Subject:* Re: Offline-enabled online book & ebook reader
>
>
>
> Hi Jake,
>
>
>
> sorry for the late reply, I was on the road last week, too (I went to
> China from Sapporo).
>
>
>
> I looked at your code. I do not claim (I could not claim:-) that I
> understand everything in the code, far from it. But I think I get a certain
> idea, also based on your explanations.
>
>
>
> What seems to be a consequence for our larger structure is that
>
>
>
> - We probably need (just as you did in the examples) a manifest that lists
> all the files that are relevant in the publication. Or… at least the
> starting versions; I would expect that it is possible to add new resources
> to the list held in the SW for caching (ie, if a client discovers new
> resources then they could be added runtime…). But a model whereby a list is
> provided as part of the publication is probably the best. This is pretty
> much what is already happening in EPUB3, nothing surprising there.
>
>
>
> - The 'trigger', in your case, is that the index.html file load the
> page.js file which then starts the process. This means that the publication
> itself is prepared; I wonder whether there is a different approach that
> does not require the 'index.html' file to know that it is part of a
> publication. This is something we will have to discuss at some point among
> ourselves, but it is a minor issue at this point compared to the overall
> picture.
>
>
>
> Thanks a lot for this!
>
>
>
> Ivan
>
>
>
>
>
> On 31 Oct 2015, at 12:42, Jake Archibald <jakearchibald@google.com> wrote:
>
>
>
> Following our meeting at TPAC, I hacked together an offline-enabled
> publication format that can be viewed as a regular page, but also
> downloaded as an archive and viewed in a separate reader site.
>
>
>
> https://jakearchibald.github.io/ebook-demo/publisher-site/readme/
>
>
>
> Hopefully this demonstrates how service worker can be used for this stuff!
>
>
>
> Cheers,
>
> Jake.
>
>
>
>
> ----
> Ivan Herman, W3C
> Digital Publishing Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>
>
>
Received on Monday, 9 November 2015 15:57:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:35 UTC