Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Nicholas Nethercote]

On Sat, Mar 10, 2018 at 11:11 AM, Myk Melez  wrote:

> If we removed XPConnect bindings entirely and converted XPIDL interfaces
> used only by C++ into concrete native classes, then what else would
> continue to need XPCOM?
>

What's your definition of XPCOM? Look in xpcom/, there is a ton of stuff in
there that is unrelated to XPIDL...

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Myk Melez]

Kris Maglione 
2018 March 8 at 16:22

Removing XPCOM entirely is not really a possibility. Removing 
XPConnect bindings entirely is... theoretically possible, but would be 
a monumental amount of work, and is not something I've heard anyone 
seriously suggest.
If we removed XPConnect bindings entirely and converted XPIDL interfaces 
used only by C++ into concrete native classes, then what else would 
continue to need XPCOM?


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Bobby Holley]

On Fri, Mar 9, 2018 at 11:53 AM, Jeff Muizelaar 
wrote:

> On Fri, Mar 9, 2018 at 7:21 AM, Ted Mielczarek  wrote:
> > On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:
> >> (C) The API uses complex arguments like promises that XPIDL doesn't
> handle
> >> in a nice way.
> >
> > I think this is an understated point. WebIDL was designed explicitly to
> allow expressing the semantics of JS APIs, where XPIDL is some arbitrary
> set of things designed by folks at Netscape a long time ago. Almost any
> non-trivial API will wind up being worse in XPIDL (and the C++
> implementation side is worse as well).
> >
> > I agree that an XPConnect-alike supporting WebIDL semantics would be a
> lot of work, but I also think that asking developers to implement chrome
> interfaces with XPIDL is pretty lousy.
>
> An alternative would be to evolve XPIDL to be more WebIDL like. I
> suspect we could fix some of the ergonomic warts incrementally with
> significantly less work than supporting the full WebIDL semantics in a
> XPConnect style.
>

Absolutely. I filed bug 1444515 (alias xpidl-warts). Please document pain
points in that bug and we can brainstorm tractable fixes.


>
> -Jeff
> ___
> 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: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Jeff Muizelaar]

On Fri, Mar 9, 2018 at 7:21 AM, Ted Mielczarek  wrote:
> On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:
>> (C) The API uses complex arguments like promises that XPIDL doesn't handle
>> in a nice way.
>
> I think this is an understated point. WebIDL was designed explicitly to allow 
> expressing the semantics of JS APIs, where XPIDL is some arbitrary set of 
> things designed by folks at Netscape a long time ago. Almost any non-trivial 
> API will wind up being worse in XPIDL (and the C++ implementation side is 
> worse as well).
>
> I agree that an XPConnect-alike supporting WebIDL semantics would be a lot of 
> work, but I also think that asking developers to implement chrome interfaces 
> with XPIDL is pretty lousy.

An alternative would be to evolve XPIDL to be more WebIDL like. I
suspect we could fix some of the ergonomic warts incrementally with
significantly less work than supporting the full WebIDL semantics in a
XPConnect style.

-Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Who can review licenses these days?

[Gregory Szorc]

On Fri, Mar 9, 2018 at 7:28 AM, David Teller  wrote:

> I'll need a license review for a vendored Rust package. Who can perform
> these reviews these days?
>

We have an allow list of licenses in our Cargo config. So if the license is
already allowed, you can reference the crate in a Cargo.toml and `mach
vendor rust` will "just work." Otherwise, we need to review the license
before any action is taken.

**Only attorneys or someone empowered by them should review licenses and
give sign-off on a license.**

You should file a Legal bug at
https://bugzilla.mozilla.org/enter_bug.cgi?product=Legal. I think the
component you want is "Product - feature." Feel free to CC me and/or Ted,
as we've dealt with these kinds of requests in the past and can help bridge
the gap between engineering and legal. We also know about how to follow up
with the response (e.g. if we ship code using a new license, we need to add
something to about:license).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Bobby Holley]

On Fri, Mar 9, 2018 at 12:15 AM, Zibi Braniecki (Gandalf) <
zbranie...@mozilla.com> wrote:

>
>
> On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley 
> wrote:
>
>> I just looked at the first 10 methods/attributes on that interface. None
>> of them are remotely performance-sensitive, and several are test-only. If
>> we see certain methods on it show up in profiles, we should move those
>> methods to WebIDL, rather than converting things wholesale per-interface.
>>
>>
>
> Are you suggesting that we build two IDLs per interface - one for
> perfomance-bound methods and the other for "non-performance-critical" ones?
>

People should default to XPIDL for internal interfaces unless they have a
compelling reason to do otherwise.
* If that reason is a frequently-invoked method, they should consider:
** Whether it needs to be invoked so frequently - could it batch instead,
or expose a different abstraction?
** Whether it really needs its own interface - could we just stick it on
ChromeUtils?
* If that reason is complex types, they should consider whether the API
actually needs to be so fancy.

If the reasons hold water, creating a new ChromeOnly WebIDL interface is
fine. Sticking a handful of ridealongs on the interface is probably also
ok, but we should be mindful of the quantity and cost, and consider
reshuffling if they pile up.

I'm just a used of XPIDL/WebIDL but I noticed that almost every interface I
> build or use has a mixture of those two types.
>
> From that perspective, ability to write a single IDL file and mark which
> functions should be perf-critical (or the opposite) would be significantly
> better UX and more fine-tunable over time.
>
> But if your recommendation is to go for two, I would really appreciate a
> tutorial explaining how to design a C++ and JS API with those two IDLs
> separating perf-critical methods from others.
>
> zb.
> p.s. I understand your concern about sinking time into developing a WebIDL
> for XPIDL replacement. At the same time, my understanding is that no matter
> how much time something took in the past, we (in general) design our
> architecture for a much longer future. So if we can introduce something
> soon that will allow all new APIs to benefit from it, the argument of how
> many APIs we already have that use the old model is diminishing.
>

My argument is not rooted in legacy considerations. If we were to sit down
today and build a "compact" binding mechanism, it would end up looking a
lot like XPConnect - including lack of support for the full expressiveness
of WebIDL. If there are specific places where we believe we could have our
cake and eat it too, we should just fix XPConnect.

On Fri, Mar 9, 2018 at 4:21 AM, Ted Mielczarek  wrote:

> On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:
> > (C) The API uses complex arguments like promises that XPIDL doesn't
> handle
> > in a nice way.
>
> I think this is an understated point. WebIDL was designed explicitly to
> allow expressing the semantics of JS APIs, where XPIDL is some arbitrary
> set of things designed by folks at Netscape a long time ago. Almost any
> non-trivial API will wind up being worse in XPIDL (and the C++
> implementation side is worse as well).
>

XPIDL works totally fine for basic methods, getters, and setters. Modern
DOM APIs use higher-level stuff, and we have to implement those with
generated C++ to maintain the strict boundaries and semantics mandated by
the spec. But for internal APIs, it seems very reasonable to keep the
JS<->C++ glue somewhat bare-bones, and implement any desired higher-level
abstractions in JS.

There will always be exceptional cases, and that's fine. But developers
need to weigh their ergonomics against any impact product quality - and
while it might be nicer to implement a niche devtools API with promises and
unions, that doesn't mean it's the right thing to do.

Code size is like memory usage - it's an aggregate metric, and we don't
have hard-and-fast rules about specific cases, but we nonetheless expect
developers to be mindful of their impact and not over-spend without good
reason.


> I agree that an XPConnect-alike supporting WebIDL semantics would be a lot
> of work,


Not just that, but also probably intractable, as I described earlier.


> but I also think that asking developers to implement chrome interfaces
> with XPIDL is pretty lousy.


That strikes me as a bit of an overstatement. Do you have a concrete
suggestion of what we should do instead?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Who can review licenses these days?

[David Teller]

I'll need a license review for a vendored Rust package. Who can perform
these reviews these days?

Thanks,
 Yoric
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Peter Van der Beken via dev-platform]

On 09/03/2018 00:06, Kris Maglione wrote:
There are different costs to WebIDL and XPIDL bindings. WebIDL bindings 
have more cost in terms of compiled code size. XPIDL have greater costs 
in terms of performance and runtime memory.


It's not that simple. In terms of runtime memory for example, XPIDL also 
has *different* costs than WebIDL (which requires a nsWrapperCache and 
CC integration). Depending on usage those might be greater or smaller.


How much have DOM peers been focusing on preventing over-use, so far? 
Granted, most of the WebIDL bindings I've created to date have been to 
address measurable performance issues, but I've never had a reviewer 
suggest that I should be worried about over-use.


I've certainly started to worry about it recently. I know you focused on 
performance sensitive interfaces specifically in your message (and in 
your patches), but I worry that that message will get lost over time. We 
really need to emphasize that there's a difference in cost. And there 
are fundamental differences between the two models that cause that.


That said, we should continue looking into reducing the cost of WebIDL 
in terms of binary size (and we are).


Peter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Ted Mielczarek]

On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:
> (C) The API uses complex arguments like promises that XPIDL doesn't handle
> in a nice way.

I think this is an understated point. WebIDL was designed explicitly to allow 
expressing the semantics of JS APIs, where XPIDL is some arbitrary set of 
things designed by folks at Netscape a long time ago. Almost any non-trivial 
API will wind up being worse in XPIDL (and the C++ implementation side is worse 
as well).

I agree that an XPConnect-alike supporting WebIDL semantics would be a lot of 
work, but I also think that asking developers to implement chrome interfaces 
with XPIDL is pretty lousy.

-Ted
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Chrome-only WebIDL interfaces no longer require DOM peer review

[Zibi Braniecki (Gandalf)]

On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley  wrote:

> I just looked at the first 10 methods/attributes on that interface. None
> of them are remotely performance-sensitive, and several are test-only. If
> we see certain methods on it show up in profiles, we should move those
> methods to WebIDL, rather than converting things wholesale per-interface.
>
>

Are you suggesting that we build two IDLs per interface - one for
perfomance-bound methods and the other for "non-performance-critical" ones?

I'm just a used of XPIDL/WebIDL but I noticed that almost every interface I
build or use has a mixture of those two types.

>From that perspective, ability to write a single IDL file and mark which
functions should be perf-critical (or the opposite) would be significantly
better UX and more fine-tunable over time.

But if your recommendation is to go for two, I would really appreciate a
tutorial explaining how to design a C++ and JS API with those two IDLs
separating perf-critical methods from others.

zb.
p.s. I understand your concern about sinking time into developing a WebIDL
for XPIDL replacement. At the same time, my understanding is that no matter
how much time something took in the past, we (in general) design our
architecture for a much longer future. So if we can introduce something
soon that will allow all new APIs to benefit from it, the argument of how
many APIs we already have that use the old model is diminishing.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform