Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills)

Seeing the discussion thread… Let me try to put my "mental model" on the subject of the WP script into some more algorithmic terms. Obviously, the details are fuzzy, and may be unrealizable, but then we have to find out what IS realizable.

The sketch below does not take into account a possible usage of the Publication manifest on top of a WAM. It may actually simplify the process to have the WAM included, based on the fact that some of the elements may already be implemented by WAM aware browsers. (I would welcome if somebody did a version with WAM included…).

With that:

* The user agent accesses the entry page of a publication.
* If the User Agent is WP aware:
 * If the entry page includes a reference to a Web Publication manifest
  * If the entry page includes a reference to a specific script (currently referred to as "WP script", possibly identified via something like type="application/javascript;profile=http://.../publication <http://.../publication>") this script is ignored (reference removed from the DOM)
  * It retrieves the manifest (see the lifecycle) and enters the publication mode
 * Otherwise, the entry page is processed as a traditional Web page
* Otherwise, the user agent handles the entry page as a traditional web site:
 * If the entry page includes a reference to a WP script, that is included and started by the UA just like any other javascript. The WP script:
  * If the entry page includes a reference to a Web Publication Manifest:
   * Consumes the manifest as described in the lifecycle
   * Enters the UA into a publication mode
  * The script stops, letting the user agent proceed with the entry page as a traditional web site
 * Nothing happens, the page is just processed as a traditional web site

The goal is to define what happens if a WP is given to a UA that does _not_ have any WP awareness whatsoever and whether we can have en environment whereby the publication has a fall-back minimal publication mode in that case. Note that, in this respect, a browser with a WP specific extension should be considered as "WP aware".

We _may_ decide that all this is too complicated or unrealistic to implement, and we should rely on WP aware browsers only. This is a decision we have to take because that may influence the core architecture. What it would mean is that users would have to install an extension to turn it into WP aware. If that is the way we go, then we can ignore many things and even the definition of fall-backs. However, the question that comes to mind is whether the deployment of Web Publications would become realistic on the Web if each and every user had to install a specific extension.

(Before jumping into the extension-only approach we should see whether something like the outline above could be achieved via a WAM controlled application!)

Taking into the multitude of browsers out there. An extension is not browser engine specific, but may be browser specific! Ie, if I run the Brave browser as my default browser, a Chrome extension would not be necessarily installable for Brave, in spite of the fact that it uses Chromium as its core engine. Such "other" browsers are out there and, in some countries like China or Russia their usage may be more important than one of the big four...

Ivan





> On 7 Feb 2018, at 21:52, Brady Duga <duga@google.com <mailto:duga@google.com>> wrote:
> 
> +1 to Hadrien. I thought the whole point of this little web adventure was to have publications that just work, today, out of the box, with no client other than a browser. A UA could also then apply more UI and navigational elements around that publication if it was capable, which is what we are trying to spec (how do you know the order of the chapters in a book, what is the title of the complete package, etc). This idea of a script associated with the document to provide some of those behaviors seems really problematic, again as Hadrien pointed out, when the UA supports some of the features and the script supports others. I am still not sure why a separate web app, extension, or whatever can't accomplish this just as well. But I am assume I am missing another discussion where we explained why we need the WP script.
> 
> On Wed, Feb 7, 2018 at 12:25 PM, Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com>> wrote:
> Right, okay now I've got you, thanks for clearing that up for me.
> 
> 
> 
> Matt
> 
> 
> 
> From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com <mailto:hadrien.gardeur@feedbooks.com>]
> Sent: February 7, 2018 3:22 PM
> 
> 
> To: Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com>>
> Cc: Romain <rdeltour@gmail.com <mailto:rdeltour@gmail.com>>; Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>; W3C Publishing Working Group <public-publ-wg@w3.org <mailto:public-publ-wg@w3.org>>
> Subject: Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills)
> 
> 
> 
> The entry page could indeed have a link to a WAM or it could simply provide a link that the user could follow as well.
> 
> 
> 
> 2018-02-07 21:12 GMT+01:00 Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com>>:
> 
> > The entry page would link to the fallback app, no need for a link in the manifest or for the browser to be WP-aware.
> 
> 
> 
> Ah, so this isn't like having a default_applications for fallback apps, but the entry page is its own WAM?
> 
> 
> 
> Matt
> 
> 
> 
> From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com <mailto:hadrien.gardeur@feedbooks.com>]
> Sent: February 7, 2018 2:48 PM
> To: Matt Garrish <matt.garrish@gmail.com <mailto:matt.garrish@gmail.com>>
> Cc: Romain <rdeltour@gmail.com <mailto:rdeltour@gmail.com>>; Ivan Herman <ivan@w3.org <mailto:ivan@w3.org>>; W3C Publishing Working Group <public-publ-wg@w3.org <mailto:public-publ-wg@w3.org>>
> Subject: Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills)
> 
> 
> 
> The entry page would link to the fallback app, no need for a link in the manifest or for the browser to be WP-aware.
> 
> 
> 
> This wouldn't get in the way of other apps for the following reasons:
> 
> a WP-aware browser would trigger the "switch to publication mode" or "add to publication list" affordances on the entry page (or any other page with a link to the manifest)
> web and native apps (including browser extensions) would only use the entry page to detect the link as well, and then they would immediately go to the first resource in the default reading order
> 
> 
> 
> 
> 
> --
> 
> Hadrien Gardeur
> 
> Co-founder, Feedbooks
> 
> http://www.feedbooks.com <http://www.feedbooks.com/>
> T: +33.6.63.28.59.69 <tel:+33%206%2063%2028%2059%2069>
> E: hadrien.gardeur@feedbooks.com <mailto:hadrien.gardeur@feedbooks.com>
> 54, rue de Paradis <https://maps.google.com/?q=54,+rue+de+Paradis+75010+Paris,+France&entry=gmail&source=g>
> 75010 Paris, France <https://maps.google.com/?q=54,+rue+de+Paradis+75010+Paris,+France&entry=gmail&source=g>


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>