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 <bobbyhol...@gmail.com> > 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 <t...@mielczarek.org> 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
