C++ standards proposal for a embedding library
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
Re: C++ standards proposal for a embedding library
It feels like the committee is burnt out on trying to solve the general library problem, but contemplating something massively complex like this instead doesn't follow, and is an answer to the wrong question. Make it easier to integrate libraries and we wouldn't see kludge proposals like this. On Wed, Jul 18, 2018 at 9:45 AM, Botond Ballo 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 3:32 PM, Jeff Gilbert wrote: > It feels like the committee is burnt out on trying to solve the > general library problem, but contemplating something massively complex > like this instead doesn't follow, and is an answer to the wrong > question. > > Make it easier to integrate libraries and we wouldn't see kludge > proposals like this. Could you elaborate on the "complexity" and "kludge" aspects? One of the main complaints about the 2D graphics proposal was that it was trying to create a new spec in a space where there are existing mature specs, and that the committee as a group doesn't necessarily have the depth of domain expertise in graphics necessary to specify a library like this. This web_view proposal attempts to address that concern by leveraging existing graphics and other specs from web standards. So, in a sense, the committee is trying to avoid dealing with complexity / reuse the work that others have done to tackle the complexity inherent in the problem space. If you're referring to the embedding mechanism / API itself being complex, it would be useful to elaborate on why. The API surface in the proposed library seems to be quite small. It's also worth noting that there is prior art in this space in the form of e.g. the QtWebView and wxWebView APIs, which I believe are fairly popular in cross-platform C++ applications, suggesting a demand for this sort of library. Note that I'm not necessarily advocating for this proposal; I'm just trying to understand the concerns / feedback better so that I can communicate them to the proposal authors effectively. If you would prefer to communicate the concerns to the authors directly, please feel free to do so. Thanks, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On 7/18/18 12:45 PM, Botond Ballo wrote: 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 Botond, Thank you for highlighting this proposal! Am I correct in my reading that this would require the C++ standard library to include an implementation of the web platform? I have specific concerns about some of the standards linked to in the "The provided web_view shall support content complying with" list, but so far I'm just trying to understand the implications of this proposal. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
CCing snorp. I guess it's interesting to see how the geckoview API differs from the webview API, and which of those differences are related to goal of that C++ API, and which are more browser-focused. And if the C++ API should be also browser-focused, in the end. Not making any statement on the interesting question of such a stdlib thing, and how that impacts choice and innovation on the web space. Which should be a more important question probably for mozilla. Axel Am 18.07.18 um 21:55 schrieb Botond Ballo: On Wed, Jul 18, 2018 at 3:32 PM, Jeff Gilbert wrote: It feels like the committee is burnt out on trying to solve the general library problem, but contemplating something massively complex like this instead doesn't follow, and is an answer to the wrong question. Make it easier to integrate libraries and we wouldn't see kludge proposals like this. Could you elaborate on the "complexity" and "kludge" aspects? One of the main complaints about the 2D graphics proposal was that it was trying to create a new spec in a space where there are existing mature specs, and that the committee as a group doesn't necessarily have the depth of domain expertise in graphics necessary to specify a library like this. This web_view proposal attempts to address that concern by leveraging existing graphics and other specs from web standards. So, in a sense, the committee is trying to avoid dealing with complexity / reuse the work that others have done to tackle the complexity inherent in the problem space. If you're referring to the embedding mechanism / API itself being complex, it would be useful to elaborate on why. The API surface in the proposed library seems to be quite small. It's also worth noting that there is prior art in this space in the form of e.g. the QtWebView and wxWebView APIs, which I believe are fairly popular in cross-platform C++ applications, suggesting a demand for this sort of library. Note that I'm not necessarily advocating for this proposal; I'm just trying to understand the concerns / feedback better so that I can communicate them to the proposal authors effectively. If you would prefer to communicate the concerns to the authors directly, please feel free to do so. Thanks, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky wrote: > Am I correct in my reading that this would require the C++ standard library > to include an implementation of the web platform? Either to include one, or to be able to find and use one provided by the OS/platform. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 4:54 PM, Botond Ballo wrote: > On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky wrote: >> Am I correct in my reading that this would require the C++ standard library >> to include an implementation of the web platform? > > Either to include one, or to be able to find and use one provided by > the OS/platform. Only if the implementation wanted to be fully compliant, correct? People were still happy to use libstdc++ (say) as an implementation of the C++ standard even when it didn't contain . Witness Boost's extensive workarounds for C++ library implementations not quite supporting something. I can imagine that embedded implementations wouldn't include , their documentation would be clear about this, and their users would be OK with this situation. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On 7/18/18 4:54 PM, Botond Ballo wrote: Either to include one, or to be able to find and use one provided by the OS/platform. Ah, ok. And in the latter case, to disable whatever network stack the OS-provided thing has, if any, and substitute its own, right? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On 7/18/18 4:59 PM, Nathan Froyd wrote: I can imagine that embedded implementations wouldn't include , their documentation would be clear about this, and their users would be OK with this situation. Oh, sure. I was talking specifically about stdlib implementation that are aiming to comply with this proposal. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 5:01 PM, Boris Zbarsky wrote: > On 7/18/18 4:54 PM, Botond Ballo wrote: >> >> Either to include one, or to be able to find and use one provided by >> the OS/platform. > > > Ah, ok. > > And in the latter case, to disable whatever network stack the OS-provided > thing has, if any, and substitute its own, right? I assume you're referring to the set_uri_scheme_handler() function in the API. My reading of the proposal is that that's an extension mechanism for the program to be able to override handling of standard URI schemes, or invent new ones (such as for serving a page from a string in the C++ program's memory), but if e.g. the program does not override the "http" URI scheme, the OS-provided implementation's default handler (including the network stack) would be used. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On 7/18/18 5:18 PM, Botond Ballo wrote: My reading of the proposal is that that's an extension mechanism for the program to be able to override handling of standard URI schemes, or invent new ones (such as for serving a page from a string in the C++ program's memory), but if e.g. the program does not override the "http" URI scheme, the OS-provided implementation's default handler (including the network stack) would be used. I'm glad we're having this conversation, because that was not obvious to me. If the intent is that the default behavior is to speak http, what are the committee's thoughts on things like sandboxing, spectre mitigations, process-per-origin, etc? This last is particularly concerning in terms of API surface, because interfacing with a multiprocess embedded browser might be quite different from interfacing with a single-process one... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 5:31 PM, Boris Zbarsky wrote: > If the intent is that the default behavior is to speak http, what are the > committee's thoughts on things like sandboxing, spectre mitigations, > process-per-origin, etc? > > This last is particularly concerning in terms of API surface, because > interfacing with a multiprocess embedded browser might be quite different > from interfacing with a single-process one... As the proposal doesn't address this explicitly, I can only speculate (no pun intended) as to the author's intentions, but I would assume that the web platform implementation's usual policies would apply; that is, if its policy is to spin up a new process for every origin, then it will do so when used via web_view as well. (Of course, library vendors may expose vendor- or platform-specific ways to tweak the behaviour of the implementation (think "flipping prefs") if there's demand for that.) The proposal hasn't been presented to the committee yet, so I can't speak to the committee's thoughts either, but I predict that there would be opposition to a design that fundamentally lacks security protections that would be present when using the web platform implementation in a usual browser context. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wednesday 2018-07-18 12:45 -0400, Botond Ballo wrote: > 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. It feels like this bakes into the C++ language the idea that a machine only ever needs a single implementation of the web platform. I (and I think many others at Mozilla) think that users are better served by competition among implementations of the Web's technology, since it allows competition to better serve the interests of users and allows more flexibility in the evolution of the platform due to fewer mistakes getting quickly baked in to the platform by compatibility. This makes me think it's a bad idea to standardize a Web View API as part of C++. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 8:04 PM, L. David Baron wrote: > It feels like this bakes into the C++ language the idea that a > machine only ever needs a single implementation of the web platform. > > I (and I think many others at Mozilla) think that users are better > served by competition among implementations of the Web's technology, > since it allows competition to better serve the interests of users > and allows more flexibility in the evolution of the platform due to > fewer mistakes getting quickly baked in to the platform by > compatibility. > > This makes me think it's a bad idea to standardize a Web View API as > part of C++. Is having a Web View API fundamentally incompatible with there being multiple implementations to select from? Suppose the API had a mechanism to query a list of available implementations, and you could specify which one to use when instantiating a web view - would that address this concern? Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
In practice, I kind of doubt that standard libraries would actually include multiple implementations of the web platform. It also seems like it could break update cadence, since standard libraries don't have nearly as rapid or streamlined and mechanism for pushing out updates. It seems like they could ossify whatever arbitrary version got shipped out in a major stdlib release. I echo the sentiment that this doesn't feel like the right approach to the problem, and that focusing on a package ecosystem makes more sense. On Wed, Jul 18, 2018, 17:13 Botond Ballo wrote: > On Wed, Jul 18, 2018 at 8:04 PM, L. David Baron wrote: > > It feels like this bakes into the C++ language the idea that a > > machine only ever needs a single implementation of the web platform. > > > > I (and I think many others at Mozilla) think that users are better > > served by competition among implementations of the Web's technology, > > since it allows competition to better serve the interests of users > > and allows more flexibility in the evolution of the platform due to > > fewer mistakes getting quickly baked in to the platform by > > compatibility. > > > > This makes me think it's a bad idea to standardize a Web View API as > > part of C++. > > Is having a Web View API fundamentally incompatible with there being > multiple implementations to select from? > > Suppose the API had a mechanism to query a list of available > implementations, and you could specify which one to use when > instantiating a web view - would that address this concern? > > Cheers, > Botond > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
On Wed, Jul 18, 2018 at 9:21 PM, Bobby Holley wrote: > In practice, I kind of doubt that standard libraries would actually include > multiple implementations of the web platform. > It also seems like the implementation(s) that get included will essentially be those those authors devote the resources to doing the development. Meaning there isn't going to be an army of stdlib devs showing up and doing the work to put Gecko into stdlib. At best someone from one of those projects will email us and say "Hey, Google is putting Chrome into the library, do you want to put Gecko?" It also seems like it could break update cadence, since standard libraries > don't have nearly as rapid or streamlined and mechanism for pushing out > updates. It seems like they could ossify whatever arbitrary version got > shipped out in a major stdlib release. > Which is a horrible, horrible idea for security. And web compatibility. And new web features. > I echo the sentiment that this doesn't feel like the right approach to the > problem, and that focusing on a package ecosystem makes more sense. > Me too. -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
