[webkit-dev] WebKit GObject bindings: Who is guiding their future?
Carlos Garcia Campos
carlosgc at webkit.org
Thu Sep 8 23:26:25 PDT 2016
El mar, 30-08-2016 a las 08:54 +0200, Carlos Garcia Campos escribió:
> El lun, 29-08-2016 a las 10:01 -0700, Darin Adler escribió:
> > >
> > > On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos <carlosgc at webki
> > > t.
> > > org> wrote:
> > >
> > > Does that mean than from the WebIDL point of view all methods can
> > > now
> > > raise a exception? If don't tell the code generator that a method
> > > can
> > > raise a exception, we assume all could return a Exception?
> > Correct.
> > Once the transition is done, the IDL will no longer indicate which
> > functions can raise exceptions; the return types of C++ member
> > functions will, instead. During the transition, exceptions can be
> > indicated in either way.
> > >
> > > It actually depends on whether this is an exception or not.
> > I’m not sure exactly what you mean. But I expect us to keep driving
> > - We will add support for more WebIDL features. There are many
> > still
> > to go. In some cases that means removing code that is currently in
> > the DOM that is doing part of the bindings work and using WebIDL to
> > implement this things. For example, translation of strings into
> > enum
> > values. WebIDL includes a specification of how all these features
> > are
> > define how to reflect each feature.
> > - We will add better exception messages, which means DOM code has
> > to
> > provide more than an exception code.
> > - We will update bindings with changes to move the web platform
> > compatibility that won’t necessarily work for other languages such
> > as
> > Objective-C. For example, the latest specifications turn
> > DOMImplementation.hasFeature into a function that ignores its
> > arguments and always returns true. That’s easy to implement with
> > somewhere that remembers what the old argument list was.
> > - We will update bindings with changes that have minimal observable
> > arguments or return values in GObject bindings, such as making a
> > return type more specific (Attr instead of Node) or changing which
> > numeric type is used.
> > - We will move things currently done in the DOM itself into the
> > bindings.
> > - We would like to change the bindings generation scripts to run
> > more
> > quickly and so that fewer run when a given IDL source file is
> > changed.
> > >
> > > If you really think that build is going to be broken often
> > > because
> > > of things very difficult to do in the GObject bindings, then we
> > > should indeed find a more general solution. Otherwise I prefer to
> > > solve this problem now, and keep the existing way of generating
> > > the
> > > bindings. We can add a rule that you can break the GObject DOM
> > > bindings build, to not block your work, and I'll try to fix it
> > > asap
> > > as we currently do with WebKit2.
> > Something like this might work. But coping with these changes is
> > going to be challenging.
> > I expect we are going to continue to run into many things we want
> > to
> > It’s taken many people hundreds of hours already to add these
> > various
> > changing both the bindings and the underlying DOM implementation.
> > I think the 88 already existing #if statements in the IDL are one
> > indication that the IDL-based code generation strategy isn’t
> > working
> > very well; *many* features that are simply not supported outside
> > the
> > features are another.
> > If you read the latest WebIDL draft <https://heycam.github.io/webid
> > l/
> > >
> > > you will see lots of features that are tricky to deal
> > with—dictionary types, enumeration types, callback function types,
> > promise types, union types, regular expressions, frozen arrays,
> > stringifiers, serializers, indexed properties, named properties,
> > overloading, map like, setlike—the only reason this is not a crisis
> > is that many web APIs are old and so not built on any of these new
> > concepts. Over time, critical features are being built on them.
> Ok, I think we can freeze the GObject bindings too, and then see how
> things go and decide what to do. From the users point of view there
> will be no difference, the current API will be available and working.
> Then, you can add any new features to WebIDL without having to worry
> about GObject bindings and we can take our time to discuss what to
> > I am OK with the “it is OK to break the GObject bindings build”
> > strategy, I guess, but are you sure you are OK with that?
> haha, no, of course I'm not, but I'm not Ok with the WebKit2 rules
> either and I just live with that :-) Anyway, I think freezing the
> GObject API is harmless and it's better for everybody.
I moved the GObject DOM API to the WebKit2 layer, so now it's ok to
break the GObject bindings in the end. The fact that there's a rule
allowing it doesn't mean you have to break it when it's so easy not to.
It has happened twice so far and the changes required were exactly the
same than the ones for objc bindings. I would appreciate if when
changing the objc bindings, you update the GObject bindings as well. I
know that our EWS is having some problems lately which doesn't help to
catch these issues, we will fix that soon.
> > — Darin
Carlos Garcia Campos
More information about the webkit-dev