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 capabilities". -- Henri Sivonen hsivo...@mozilla.com _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
