On Tue, Oct 22, 2019 at 11:55 PM Botond Ballo <bba...@mozilla.com> wrote:
> Given that, would anyone be interested in reviewing the proposed API
> and providing feedback on its design? I feel like the committee would
> be receptive to constructive technical feedback, and as a group with
> experience in developing embedding APIs, we are in a particularly good
> position to provide such feedback.
> The latest draft of the proposal can be found here:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1108r4.html

These comments are still more on the theme of this API being a bad
idea for the standard library on the high level as opposed to being
design comments on the specifics.

Section 4.2 refers to Gecko's XPCOM embedding API, which hasn't been
supported in quite a while. It also refers to the Trident embedding
API. Putting aside for the moment the it's bad from Mozilla
perspective to treat a Web engine as a generic platform capability as
opposed to it being a thing that one chooses from a number of
competitive options, it seems bad to build on the assumption that on
Windows the platform capability is Trident, which isn't getting new
Web features anymore.

Further on the Trident point, it doesn't really work to both say that
this is just exposing a platform capability and to go on to say that
implementations are encouraged to support [list of Web specs]. This
sort of thinking failed for the various Web on TV initiatives that got
whatever Presto and WebKit had. If the mechanism here is the Trident
embedding API on Windows, then you get whatever Trident has.

I'm curious how developers of libstdc++ and libc++ view the notion of
WebKitGTK+ as a platform capability. The C++ standard libraries are
arguably for Linux while the "platform capability" named (WebKitGTK+)
is arguably a Gnome thing rather than a Linux-level thing. That WPE
WebKit exists separately from WebKitGTK+ seems like a data point of
some kind: https://wpewebkit.org/

Section 4.4 argues against providing a localhost Web server
capability. I understand that the goal here is a user experience that
differs from the experience of launching a localhost HTTP server and
telling a Web browser to navigate to a localhost URL. However, the
additional arguments about the HTTP/2 and HTTP/3 landscape evolving
quickly and requiring TLS seem bad.

For localhost communication, HTTP/1.1 should address the kind of use
cases presented (other than the launch UX). Without actual network
latencies, HTTP/2 and HTTP/3 optimizations over HTTP/1.1 aren't _that_
relevant. Also, the point about TLS doesn't apply to HTTP/1.1 to
localhost. The notion that it's easier to create a multi-engine Web
engine embedding API that allows the embedder to feed the Web engine
pseudonetwork data is simpler than creating a localhost HTTP/1.1
server seems like a huge misestimation of the relative complexities.

Moreover, for either this API and a local HTTP server to work well, a
better way of dynamically generating HTML than is presented in the
example is required. It doesn't make sense to me to argue that
everything belongs in the standard library to the point of putting a
Web engine API there if a mechanism for generating the HTML to talk
with the Web engine doesn't belong in the standard library. If the
mechanism for generating the HTML is something you pull from GitHub
instead of something you get in the standard library, why can't
https://github.com/hfinkel/web_view be pulled from GitHub, too?

Finally, this seems very hand-wavy in terms of the security aspects of
loading remote content in a Web engine launched like this. My
understanding is that this has been an area of security problems for
Electron apps. It seems irresponsible not to cover this in detail, but
it also seems potentially impossible to do so, given the need to work
with whatever Web engine APIs that already exist as "platform

Henri Sivonen
dev-platform mailing list

Reply via email to