Should there be a pure “JavaScript” version? about architecture HOT 12 CLOSED

I think it largely depends what you mean by "a pure Javascript version". Do you mean a full app in JS? Or simply make sure that every core component has a JS version available?

Right now I would divide what I have in mind for Readium 2 in two big parts:

• one part is responsible for the container: it outputs a manifest and provides access to the resources in the container
• another part is tied to the browser engine/reading experience, and handles pagination, page turns, annotations etc.

It's pretty clear that at least some if not all of the second part will be implemented in JS.

from architecture.

Re the first part (EPUB parsing), do you think that a pure JS lib (zip.js?) could do the trick? I suppose optimizing the access to the resources in the archive is not done in such a lib. If a JS zip lib can only created unzipped files, it does not seem a great solution.

from architecture.

I think the first part should be entirely optional for a Web App.

I could decide to have the equivalent of the first part run on my server instead, and write it in Go for example. If the output is standardized (manifest) then it doesn't really matter if the first part is handled by a distant server, a C++ app running on the same device or something else.

from architecture.

@HadrienGardeur for a pure Web App I totally agree (content loaded from the Web). My question was about apps using local EPUB files.

Now let's imagine a Web App that can "side load" or "export locally" an EPUB file. The zip issue still exists, and optimizing resource loading is required I guess.

from architecture.

Modularity between the parsing and the reading seem like it will really pay off here.

While using something like jszip and some combination of data urls, blobs, indexeddb, or service workers can make a nice solution for using javascript as a client side parser & server, loading directly from zipped epub in a browser is somewhat of an edge case and there may be several good ways to do it. It does enable some interesting abilities like loading directly from an input form or cloud storage provider.

I think, with a standardized interface, this might be a good place for something like Epub.js to fill in some of the gaps in what Readium needs to support out of the box.

from architecture.

@fchasen Our experience of loading from a zipped EPUB is basically, don't do it if the EPUB is remote. See the doc here Do you have a different view or experience?

from architecture.

I definitely agree that it is problematic for all the reasons in that doc, and it makes sense to have a server handle that part.

However, it can also work well enough for many books to make the use cases it enables worth considering.

from architecture.

I agree with Fred but I would actually vote for an even more radical
modularization.

I think that we will need to be looking feature by feature at everything in
EPUB and seeing how those features can be used for website content as well
as packaged publications. By way of a long-standing example, there is no
reason not to be able to use Media Overlays on any website as a modular
feature. Significant format work will be needed to figure out how to do
these things modularly (it's easy to say let's make Media Overlays work for
websites but you don't want to pull in OPF to do so so you need to at a
minimum invent some "link rel=" or other means to designate it). And I'm
not sure that this format work will ripen in the timeframe for Readium 2.
But it might and I think R2 will be best set up for the future if we don't
think of it as monolithically supporting a monolithic format but as
modularly supporting a set of modular features (that just happened to all
be balled up together in today's EPUB 3) with a set of polyfills that can
be used separately when appropriate.

Another example is navigation. To me there is no reason that JS code that
finds a

Dynamic loading of MathJAX to support MathML is another example of what IMO
should be a separate polyfill.

And pagination. We don't paginate across content documents only within
them. So why not treat our pagination code as a modular polyfill that can
be used on any website that wants to offer a paginated view (and perhaps
literally a polyfill by implementing overflow=page or whatever).

I would therefore make it a requirement that the R2 support in JS for any
given feature MUST be usable on a standalone basis and therefore MUST NOT
know about any other feature. If we discover that there are subcomponents
that need to be used by more than one R2 feature then those are shared
supporting libraries/dependencies (we don't want to be loading 5 copies of
backbone.js because 5 R2 feature polyfills use backbone.js but that is a
normal issue in developing JS web apps).

Again this is kind of a radical idea and I'm not suggesting it's the only
way to go but I do think that the technical team should seriously consider
it and its implications given the likely future directions at the format
level.

--Bill

On Wed, Oct 12, 2016 at 7:23 AM, Fred Chasen [email protected]
wrote:

Modularity between the parsing and the reading seem like it will really
pay off here.

While using something like jszip and some combination of data urls, blobs,
indexeddb, or service workers can make a nice solution for using javascript
as a client side parser & server, loading directly from zipped epub in a
browser is somewhat of an edge case and there may be several good ways to
do it. It does enable some interesting abilities like loading directly from
an input form or cloud storage provider.

I think, with a standardized interface, this might be a good place for
something like Epub.js to fill in some of the gaps in what Readium needs to
support out of the box.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABCE3ODF8dzbz5x18xnR763j6LMmJ1Vdks5qzO1PgaJpZM4KDIg_
.

from architecture.

Thanks @whmccoy I copied your comment here: #8 (comment)

from architecture.

Would there be any objection to sharing the document linked in @rkwright's comment above with the W3C's DPUB Interest Group--their mailing list is public (and I know at least @danielweck frequents it from time to time)?
https://lists.w3.org/Archives/Public/public-digipub-ig/

There's ongoing discussion about packaging, zip, etc, on that list and having implementer input is valuable even before the Interest Group creates sub-Working Groups (which is forthcoming).

I'd love to share these specific documents and this issue with that group (which I'm a part of, btw), but @danielweck at least is also on that mailing list and it's probably best to come directly from the source. 😄

Any objections? @danielweck would you like to do the honors? 😃

from architecture.

@BigBlueHat No objections from me whatsoever. All the docs should be public except those for the Readium board (which you can't see anyway). But I'll let Daniel "do the honors".

from architecture.

Just in case you did not know: I took part in the original DPUB / PWP discussion regarding the use of Service Workers (with valuable insider / developer input from Jake Archibald), and around the same time I implemented Readium 's SW proof of concept. More recently I posted clarifications to the DPUB GitHub: w3c/dpub-pwp-ucr#110 (comment)
w3c/dpub-pwp-ucr#110 (comment)

Although the Google Docs linked by Ric are available publicly, they are primarily geared towards internal development / brainstorming discussions. Perhaps not the best material for standard-related discussions. I would be happy to chime-in again during the DPUB concalls, should the opportunity to discuss SW usage arised - especially in the context of packaging / container-ing (in the Readium prototype I wasn't aiming to enable caching or an offline mode, I just wanted to "emulate" individual EPUB resource URLs, by inflating / unzipping content streams on the fly, on the client side).

from architecture.