Re: C++ standards proposal for a embedding library
We that's bleak. Get pumped for a surge in "Download our desktop app for the full experience"! Rather than spending our limited resources giving guiding technical feedback to proposals we fundamentally oppose, I would rather see us putting effort into satisfying the target user stories with a less catastrophic proposal. A bunch of senior engineering has chimed in here, but I would love to know that this is being surfaced to upper leadership. Thanks for keeping us all apprised, Botond. On Tue, Oct 22, 2019 at 1:55 PM 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 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
Upcoming C++ standards meeting in Belfast
Hi everyone! The next meeting of the C++ Standards Committee (WG21) will be November 4-9 in Belfast, Northern Ireland. This meeting will be focused on bug fixing and stabilization for C++20, which has achieved feature-complete status at the last meeting. The C++20 draft contains a number of significant new features, including Concepts, Modules, Coroutines, Ranges, and default comparisons (Contracts has slipped to C++23), so undoubtedly there will integration and stabilization work to be done. In parallel, the Evolution groups will start looking at C++23 material. A proposal for the committee's high-level direction for C++23 can be found here [1]; some significant items there include contracts, networking, reflection, and pattern matching. I'd also like to call particular attention to the web_view proposal that is the subject of another dev-platform thread [2]. If you're curious about the state of C++ standardization, I encourage you to check out my blog posts where I summarize each meeting in detail (most recent one here [3]), and the list of proposals being considered by the committee (new ones since the last meeting can be found here [4] and here [5]). I will be attending this meeting, splitting my time between the Evolution Working Group Incubator (which I've been roped into chairing at this meeting), and the Evolution Working Group itself (on days when the Incubator isn't running), perhaps also visiting the Reflection Study Group if time permits. As always, if there's anything you'd like me to find out for you at the meeting, or any feedback you'd like me to communicate, please let me know! Finally, I encourage you to reach out to me if you're thinking of submitting a proposal to the committee. I'm always happy to help with formulating and, if necessary, presenting a proposal. Cheers, Botond [1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/p0592r3.html [2] https://groups.google.com/d/msg/mozilla.dev.platform/HGjLpdUaLsI/qxjSXwqrAAAJ [3] https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-2019/ [4] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-08 [5] http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/#mailing2019-10 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ standards proposal for a embedding library
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 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
Re: Using MozPhab without Arcanist
This is great, thank you zalun! moz-phab has improved by leaps and bounds over the last few months. Great job to you and the team hacking on it - it's a critical part of my toolset. On Tue, 22 Oct 2019 at 11:26, Piotr Zalewa wrote: > Hi all, > > Since today MozPhab does not require Arcanist to submit patches in all > supported VCS's. It's an optional and experimental feature. Add the > `--no-arc` option to switch it on. > > Feel free to use it and report any bugs the usual way - > > https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit=moz-phab > > Let's all hope not using Arcanist will soon become the default. > -- > Piotr Zalewa (zalun) > Mozilla > ___ > 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
Using MozPhab without Arcanist
Hi all, Since today MozPhab does not require Arcanist to submit patches in all supported VCS's. It's an optional and experimental feature. Add the `--no-arc` option to switch it on. Feel free to use it and report any bugs the usual way - https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit=moz-phab Let's all hope not using Arcanist will soon become the default. -- Piotr Zalewa (zalun) Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: CSS subgrid
On 22/10/2019 00:07, L. David Baron wrote: On Monday 2019-10-21 16:01 -0500, Mike Taylor wrote: Hi David, On 10/21/19 7:22 AM, L. David Baron wrote: (That we haven't applied the policy that much because we've granted exceptions because other browsers have shipped the features reduces the effectiveness of the policy and its ability to meet its goals. This is the sort of policy that is most effective if it applies to the largest number of thngs, both because it has larger effects and because it sets much clearer expectations about what will be limited to secure contexts. I think it's worth considering reducing that exception to the existence of actual web compat problems from the secure contexts limitation.) Can you unpack this a little here? Are we saying we would ship features in non-secure contexts because sites theoretically rely on that behavior due to another browser shipping as non-secure before we did? (This sounds like the current rationale for exceptions, I think). Or are we saying we would ship a feature by default as secure and be willing (compelled?) to move to non-secure if we discover sites rely on other significant market share browsers not requiring a secure context for said feature -- once our users reported the bugs (or we did some kind of analysis beforehand)? I'm saying that we've been doing what you describe in the first paragraph but maybe we need to shift to what you describe in the second paragraph in order for the policy on secure contexts to be effective. Shipping a Gecko-first feature limited to secure contexts, when we don't have evidence that other browsers will follow suite, runs the risk of sites breaking only in Gecko once the feature is widely deployed. Although we can always change the configuration after breakage is observed, the time taken to receive a bug report, diagnose the issue, and ship the fix to users, can be significant. This is a window during which we're likely to lose users due to the — avoidable — compatibility problems. I would argue that in the case where: * There is no compelling security or privacy reason for limiting a feature to secure contexts * There is reason to suspect that other browsers will ship a feature in both secure and insecure contexts (e.g. because limiting to secure contexts would be significant extra work in their engine, or because their past behaviour suggests that the feature will available everywhere) the trade-off between nudging authors toward https usage, and avoiding web-compat hazards should fall on the side of minimising the compatibility risk, and so we should ship such features without limiting to secure contexts. Alternatively we could have a policy that allows us to initially ship Gecko-first features meeting the above criteria as secure-context only, but that requires us to remove the limit if other browsers start shipping to their development channels without a secure-context limit. That minimises the compatibility risk — assuming we follow through on the process — but adds extra bureaucracy and has more steps to go wrong. I doubt the incremental effect on https adoption of this policy variant is worth the additional complexity, and suggest we should use this approach only if we misjudge the intentions of other vendors. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
