Is there some visibility into the feedback by other participants (esp.
other browser vendors) and why they think this is a good idea? What are
the arguments *for* this thing, and have they engaged with our arguments
against at all?
As a desktop Firefox person, "embedding" Gecko and providing UI on top
is at some level what we do - with the added bonus that we can change
Gecko to suit us if necessary (a luxury embedders generally do not have).
From experience, people seriously underestimate how hard this is -
things like "I want a URL bar" or "I want tabs / multiple navigation
contexts and want them to interact correctly" or "users should be able
to download files and/or open them in helper apps cross-platform" are
considerably less trivial than most people seem to assume, and even as
Mozilla we have (perhaps embarrassingly) repeatedly made the same /
similar mistakes in these areas when creating new "embedders" from
scratch (Firefox for iOS, FirefoxOS, the various Android browsers), or
have had to go over all our existing separate gecko consumers to adjust
them to new web specs (most recent example I can think of is same site
cookies, for instance, which requires passing along origin-of-link
information for context menu or similar affordances), which is
non-trivial and of course cannot happen without embedding API
adjustments. That's before we've talked about the embedded code itself
changing requirements (e10s, fission, sandboxing improvements, ...).
When looking at the objections our senior engineers had already raised
earlier in this thread, I was struck by Ted's point about a module
system - avoiding specifying a module system because "it's hard" (which
I too don't disbelieve, fwiw), but instead trying to specify a web
embedding API looks to me like the inverse of "better the devil you
know" on the part of the C++ standard library folks - fundamentally, a
module system is a more constrained thing than "please provide a
complete API for interacting with the web".
Finally, I'll point out that in all this time, it seems (from searching
the web, that is) the standard library committee has not specified a
standard API for either sockets or HTTP(S) connections - a very very
tiny subset of "web view", instead leaving everyone to integrate
libcurl/neon/boost.asio/whatever as they see fit. It seems odd to go
straight from "nothing" to "web view", and not start with the building
blocks... Similar arguments could be made for xml/html parsing, JS
engine support, CSS parsing, layout, etc.
(apparently there is/was a networking/socket (but not http/https - or
even tls itself) proposal but afaict it hasn't been integrated in any of
the finished standards so far?)
~ Gijs
On 22/10/2019 21:54, Botond Ballo wrote:
Hi folks,
I wanted to give an update on the "web_view" C++ standard library proposal.
I have relayed the feedback received on this thread on multiple
occasions, and our concerns about this proposal as a browser
implementer have been noted by the committee. However, the proposal
has been received positively by other participants of the committee,
including other browser vendors, and is continuing to be developed and
reviewed. While it's still at an early stage (still in front of the
Library Evolution Incubator group), it is being actively developed and
the proposed API is becoming more fleshed out.
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
Thanks!
Botond
On Wed, Jul 18, 2018 at 12:45 PM Botond Ballo <bba...@mozilla.com> wrote:
Hi everyone,
With the proposal for a standard 2D graphics library now on ice [1],
members of the C++ standards committee have been investigating
alternative ways of giving C++ programmers a standard way to write
graphical and interactive applications, in a way that leverages
existing standards and imposes a lower workload on the committee.
A recent proposal along these lines is for a standard embedding
facility called "web_view", inspired by existing embedding APIs like
Android's WebView:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1108r0.html
As we have some experience in the embedding space here at Mozilla, I
was wondering if anyone had feedback on this embedding library
proposal. This is an early-stage proposal, so high-level feedback on
the design and overall approach is likely to be welcome.
Thanks!
Botond
[1]
https://botondballo.wordpress.com/2018/06/20/trip-report-c-standards-meeting-in-rapperswil-june-2018/
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
