Handling WPs on the Web, was Re: Jotting down some discussion topics

>From the notes:

> There is also an orthogonal issue that came up, which may be more related to how a WP would
> be handled on the Web. If, in abstract, we talk about a WP Processor, most probably implemented
> on top of Service Workers, what is the processing model.

I'll note that talking about a  WP Processor might be premature. We've
not shown that a WP is not just a collection of web pages (i.e., there
might not be any additional processing involved on the side of the
browser, or we can't just talk about "user agent").

> Is a WP:
>
> 1. A separate application relying on a browser engine (but with its own chrome)

Hopefully not.

> 2. Some sort of an extension or add-on (I am not sure what exactly is the right term these
> days, and we have to explore that) relying on a browser, but re-using the browser chrome.

Creating a plugin (or, better, using something like Electron) might be
a good start. It's still a browser tho.

> Ie, if I have, say, a hypothes.is annotation extension added to my browser, I should be
> able to use it when consuming a WP

It would be very sad if hypothes.is doesn't become, or is not already,
a web service. Are they involved in this effort?

Having a chrome only extension is, meh. ¯\_(ツ)_/¯

> 3. There is no WP, in fact, because the browser does it all.

As representing a browser vendor (Mozilla), I'm super bias - but it
would be very sad if the users of the web didn't benefit from this
effort. So yes, we would want the browser to do it all and we should
fight really really hard to make sure browsers do it all for the
benefit of all:)

> (My personal feeling is that No. 1 is of course possible but not very interesting (this
> is what current ebook readers do already, nothing new there). The ideal thing would be
> No. 3, but that may be considered as a long-term goal; different browser vendors may have
> different interest and they may decide that a WP is not a "fundamental" feature that should
> be on the Web. I guess No. 2 is the realistic model that we should have.)

For an IG, yes: a good proof of concept could work ala 2. However,
there is a lot of overlap between this effort and other efforts
underway at the w3c - efforts I'd like to point out go beyond the
requirements that this group has jotted down in really really exciting
ways (e.g., web manifest, wake lock API, network information API, web
share API, the whole suite of service workers background sync +
"foreign fetch", etc.) - and this effort's requirements can directly
motivate and inform decisions in those other efforts. So, we might be
able to prototype the future much more quickly and directly by getting
bits that meet the requirements piecemeal into browsers (and we might
not even need to lift a finger a lot of the time).

Kind regards,
Marcos

Received on Wednesday, 21 September 2016 01:36:14 UTC