<div dir="ltr">On Fri, Mar 9, 2018 at 12:15 AM, Zibi Braniecki (Gandalf) <span dir="ltr"><<a href="mailto:zbraniecki@mozilla.com" target="_blank">zbraniecki@mozilla.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Mar 8, 2018 at 7:09 PM, Bobby Holley <span dir="ltr"><<a href="mailto:bobbyholley@gmail.com" target="_blank">bobbyholley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span></span><span></span><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div><span><div> <br></div></span></div></div></div></blockquote><div><br></div></span><div>Are you suggesting that we build two IDLs per interface - one for perfomance-bound methods and the other for "non-performance-critical" ones?</div></div></div></div></blockquote><div><br></div><div>People should default to XPIDL for internal interfaces unless they have a compelling reason to do otherwise.<br></div><div>* If that reason is a frequently-invoked method, they should consider:</div><div>** Whether it needs to be invoked so frequently - could it batch instead, or expose a different abstraction?</div><div>** Whether it really needs its own interface - could we just stick it on ChromeUtils?</div><div>* If that reason is complex types, they should consider whether the API actually needs to be so fancy.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><span class="m_8324841040001981175HOEnZb"><font color="#888888"><div><br></div><div>zb.</div></font></span><div>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.<br></div></div></div></div>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">On Fri, Mar 9, 2018 at 4:21 AM, Ted Mielczarek <span dir="ltr"><<a href="mailto:ted@mielczarek.org" target="_blank">ted@mielczarek.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_8324841040001981175gmail-">On Thu, Mar 8, 2018, at 7:41 PM, Bobby Holley wrote:<br>
> (C) The API uses complex arguments like promises that XPIDL doesn't handle<br>
> in a nice way.<br>
<br>
</span>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).<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I agree that an XPConnect-alike supporting WebIDL semantics would be a 
lot of work,</blockquote><div><br></div><div>Not just that, but also probably intractable, as I described earlier.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> but I also think that asking developers to implement chrome
 interfaces with XPIDL is pretty lousy.</blockquote></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">That strikes me as a bit of an overstatement. Do you have a concrete suggestion of what we should do instead?<br></div></div>