Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

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  > > 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
> > JavaScript DOM bindings forward in lots of ways. Here are a few:
> > 
> > - 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
> > reflected in JavaScript, but for non-JavaScript bindings we have to
> > 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
> > forward, with JavaScript-specific strategies for backward
> > 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
> > WebIDL for JavaScript, but for GObject and Objective-C we need code
> > somewhere that remembers what the old argument list was.
> > 
> > - We will update bindings with changes that have minimal observable
> > effect in the JavaScript type system but have effects on types of
> > 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
> > do for JavaScript that are difficult to do in the GObject bindings.
> > It’s taken many people hundreds of hours already to add these
> > various
> > WebIDL features for the JavaScript bindings, and each one involved
> > 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
> > JavaScript code generator because they use one of the newer IDL
> > features are another.
> > 
> > If you read the latest WebIDL draft  > 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
> do.
> 
> > 
> > I am OK with the “it is OK to break the GObject bindings build”
> > strategy, I guess, but 

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 19:00 +0200, Carlos Garcia Campos escribió:
[...]
> I just need some time, I'm very busy this week because I have to make
> a
> new branch for WebKitGTK+ 2.14 and prepare a new release. Good thing
> is
> that I made the branch today, so changes in trunk are less risky for
> us
> now, and I plan to make the release tomorrow. As soon as the release
> is
> out, I'll start working on the bindings freeze.

I've just attached a patch here:
https://bugs.webkit.org/show_bug.cgi?id=161438

For now I've copied all the generated code, as a first step, but I
think we can actually remove a lot of code from the unstable part that
nobody is using. But before removing anything, I need to check what
unstable APIs applications are using and ask the WebKitGTK+ community.
Then I'll move all that to the stable part and remove the rest of the
unstable API, since we can add any new API on demand if any
applications need it.

> > 
> > — Darin
-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 09:52 -0700, Darin Adler escribió:
> Thanks for the frank discussion, guys.
> 
> I do think we may be able to make the GObject bindings better and
> better over time even if they are hand written rather than generated.

Exactly.

> I understand that you want to keep them vital and up to date in a way
> that the Apple folks are not planning to do for the Objective-C
> bindings. Given the goal to have them be stable even while adding new
> capabilities with new ones, I hope it will be practical to make them
> great without using automatic generation.

We split the API long time ago and since then we have never added new
methods/properties to the stable part, and very few applications use
the unstable part (and they only use one or two methods). So, I don't
think it will be a problem at all to stop auto-generating them.

> I also think it’s worth further discussion with some of the folks at
> Apple who also want to make sure we have great API for use inside
> injected bundles. We might come up with some idea that is excellent
> both for Cocoa and GTK.
> 
> Can we plan how to do the transition off of automatic generation now,
> or is there anyone else we should consult?

I just need some time, I'm very busy this week because I have to make a
new branch for WebKitGTK+ 2.14 and prepare a new release. Good thing is
that I made the branch today, so changes in trunk are less risky for us
now, and I plan to make the release tomorrow. As soon as the release is
out, I'll start working on the bindings freeze.

> — Darin
-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Darin Adler]

Thanks for the frank discussion, guys.

I do think we may be able to make the GObject bindings better and better over 
time even if they are hand written rather than generated. I understand that you 
want to keep them vital and up to date in a way that the Apple folks are not 
planning to do for the Objective-C bindings. Given the goal to have them be 
stable even while adding new capabilities with new ones, I hope it will be 
practical to make them great without using automatic generation.

I also think it’s worth further discussion with some of the folks at Apple who 
also want to make sure we have great API for use inside injected bundles. We 
might come up with some idea that is excellent both for Cocoa and GTK.

Can we plan how to do the transition off of automatic generation now, or is 
there anyone else we should consult?

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El mar, 30-08-2016 a las 06:10 -0500, Michael Catanzaro escribió:
> I'm OK with freezing the bindings. I'm disappointed in that these are
> a
> killer feature for us and they'll never get improved now, but
> generating them seems to be causing too many problems that we cannot
> easily solve.

why do you say they are never going to be improved? we haven't even
started to decide what we are going to do. The only change for now is
that they are not going to be auto-generated.

> On Tue, 2016-08-30 at 08:54 +0200, Carlos Garcia Campos wrote:
> > 
> > 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.
> 
> The difference is that the GObject bindings are a seriously difficult
> issue for Apple that materially slows down their development (or at
> least appears to me to do so). It's impressive how much extra effort
> Apple devs (hi Chris) have spent trying to keep our bindings building
> (thanks!), but I don't think it's reasonable to expect them to do so.
> As much as we appreciate it, really nobody should be spending an
> afternoon uploading speculative patches to try to please our bindings
> generator. Anyway, if we freeze the API, this becomes a moot point.
> 
> WebKit2 is totally different. When WebKit2 breaks (which has
> fortunately become much rarer nowadays than it used to be) it's
> usually
> something very very easy to fix -- a function gains an extra
> parameter
> or a pointer becomes a reference or something -- and it just feels
> borderline spiteful to not spend five minutes with 'git grep' to
> avoid
> breaking us. It's not as if WebKit2 is somehow less important to us
> than WebCore

I guess you never had to deal with any failure.

> Michael
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Michael Catanzaro]

I'm OK with freezing the bindings. I'm disappointed in that these are a
killer feature for us and they'll never get improved now, but
generating them seems to be causing too many problems that we cannot
easily solve.

On Tue, 2016-08-30 at 08:54 +0200, Carlos Garcia Campos wrote:
> 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.

The difference is that the GObject bindings are a seriously difficult
issue for Apple that materially slows down their development (or at
least appears to me to do so). It's impressive how much extra effort
Apple devs (hi Chris) have spent trying to keep our bindings building
(thanks!), but I don't think it's reasonable to expect them to do so.
As much as we appreciate it, really nobody should be spending an
afternoon uploading speculative patches to try to please our bindings
generator. Anyway, if we freeze the API, this becomes a moot point.

WebKit2 is totally different. When WebKit2 breaks (which has
fortunately become much rarer nowadays than it used to be) it's usually
something very very easy to fix -- a function gains an extra parameter
or a pointer becomes a reference or something -- and it just feels
borderline spiteful to not spend five minutes with 'git grep' to avoid
breaking us. It's not as if WebKit2 is somehow less important to us
than WebCore

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 10:01 -0700, Darin Adler escribió:
> > On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos  > 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
> JavaScript DOM bindings forward in lots of ways. Here are a few:
> 
> - 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
> reflected in JavaScript, but for non-JavaScript bindings we have to
> 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
> forward, with JavaScript-specific strategies for backward
> 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
> WebIDL for JavaScript, but for GObject and Objective-C we need code
> somewhere that remembers what the old argument list was.
> 
> - We will update bindings with changes that have minimal observable
> effect in the JavaScript type system but have effects on types of
> 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
> do for JavaScript that are difficult to do in the GObject bindings.
> It’s taken many people hundreds of hours already to add these various
> WebIDL features for the JavaScript bindings, and each one involved
> 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
> JavaScript code generator because they use one of the newer IDL
> features are another.
> 
> If you read the latest WebIDL draft  > 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 do.

> 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.

> — Darin
-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lis

Re: [webkit-dev] WebKit GObject bindings: Who is guiding their future?

[Darin Adler]

> On Aug 29, 2016, at 1:16 AM, Carlos Garcia Campos  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 JavaScript 
DOM bindings forward in lots of ways. Here are a few:

- 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 reflected in JavaScript, but for 
non-JavaScript bindings we have to 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 forward, with 
JavaScript-specific strategies for backward 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 
WebIDL for JavaScript, but for GObject and Objective-C we need code somewhere 
that remembers what the old argument list was.

- We will update bindings with changes that have minimal observable effect in 
the JavaScript type system but have effects on types of 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 do for 
JavaScript that are difficult to do in the GObject bindings. It’s taken many 
people hundreds of hours already to add these various WebIDL features for the 
JavaScript bindings, and each one involved 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 JavaScript code generator 
because they use one of the newer IDL features are another.

If you read the latest WebIDL draft  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.

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?

— Darin___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 07:54 -0500, Michael Catanzaro escribió:
> On Mon, 2016-08-29 at 14:45 +0200, Carlos Garcia Campos wrote:
> > 
> > I agree this is not ideal for a GObject API, but I really don't see
> > how
> > this is a major problem, to be honest.
> 
> The problem is that you would either have to check for errors on
> every
> function call, including the 95% of function calls that cannot throw
> errors, or just ignore all errors.

That's why I asked Darin if now all DOM methods can raise exceptions,
because that information is no longer in the idl. If we keep the GError
model, we would need to add a GError parameter to every public method,
so that would be the same problem. If we change the exception model and
we know which methods can raise exceptions we can simply document it.

I see a problem for gobject-instrospection bindings more than C
developers.

> I guess if most API users ignore errors, it's not such a big deal.
> 
> Michael
> 
-- 
Carlos Garcia Campos

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Michael Catanzaro]

On Mon, 2016-08-29 at 14:45 +0200, Carlos Garcia Campos wrote:
> I agree this is not ideal for a GObject API, but I really don't see
> how
> this is a major problem, to be honest.

The problem is that you would either have to check for errors on every
function call, including the 95% of function calls that cannot throw
errors, or just ignore all errors.

I guess if most API users ignore errors, it's not such a big deal.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El lun, 29-08-2016 a las 07:21 -0500, Michael Catanzaro escribió:
> On Mon, 2016-08-29 at 10:16 +0200, Carlos Garcia Campos wrote:
> > 
> > We basically have a Exception member
> > in WebKitDOMObject base class that is reset for every method call,
> > and
> > set in case of exception. Then we add
> > webkit_dom_object_get_exception()
> > to query if there were a exception. That's not the GLib way, but
> > DOM
> > bindings is a special API anyway.
> 
> It would be a major usability regression for developers. :(
> 

I don't see why. Most of the code using DOM bindings simply ignores the
errors, and existing code is not going to change. I don't see any major
usability issue, neither any regression at all. Is it really a major
usability going from:

GError *error = NULL;
webkit_dom_foo_do_bar (foo, &error);
if (error) {
    handle_error();
    g_error_free (error);
}

to

webkit_dom_foo_do_bar (foo);
error = webkit_dom_foo_get_error (foo);
if (error)
    handle_error();

It even has advantages, for example if you are not interested in the
error details you can null-check the return value of get_error()
without having to worry about freeing the GError. 

I agree this is not ideal for a GObject API, but I really don't see how
this is a major problem, to be honest.

-- 
Carlos Garcia Campos
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Michael Catanzaro]

On Mon, 2016-08-29 at 10:16 +0200, Carlos Garcia Campos wrote:
> We basically have a Exception member
> in WebKitDOMObject base class that is reset for every method call,
> and
> set in case of exception. Then we add
> webkit_dom_object_get_exception()
> to query if there were a exception. That's not the GLib way, but DOM
> bindings is a special API anyway.

It would be a major usability regression for developers. :(
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Carlos Garcia Campos]

El sáb, 27-08-2016 a las 23:12 -0700, Darin Adler escribió:
> 
> Hi folks.
> 
> You may have noticed the substantial improvements we’ve made to our
> WebIDL support over the last year.
> 
> Also, the last few days I’ve been working on one small exciting
> improvement to our JavaScript bindings. We can express exceptions as
> a special return value inside the DOM implementations,
> ExceptionOr, instead of using an ExceptionCode& out
> argument. This has many benefits; one of them is that we don’t need
> the [RaisesException] family of extended attributes to generate
> JavaScript bindings. Instead the bindings use C++ templates to
> generate exception-propagating code when needed based on function
> return types without having to specify anything in the IDL.

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?

> 
> The first step in this direction is in
> .

I'll take a look.

> 
> For Objective-C bindings, our approach is now that instead of trying
> to implement WebIDL features, we instead hand maintain a legacy set
> of bindings as we change the underlying DOM implementation. This
> works because we decided to “freeze” the bindings and no longer
> intend to automatically generate them or have them automatically
> track additions to the web platform. For WebKit at Apple, we consider
> the Objective-C bindings a part of the legacy WebKit, and for the
> modern WebKit API (WebKit2) we use different approaches inside
> injected bundles, such as dynamically bridging from Swift and
> Objective-C to JavaScript rather statically bridging to the DOM.
> Stability is more important than features for our Objective-C
> bindings; they are there largely for compatibility rather than being
> our favorite forward-looking API for manipulating webpage content.

In the GTK+ port the GObject DOM bindings API is a key feature, and
it's used by most of the applications using WebKitGTK+. When we
switched to WebKit2 we realized we could keep the exactly same API,
exposed via injected bundle. This made porting applications from
WebKit1 to WebKit2 a lot easier, because it made possible to just move
some existing code to the injected bundle.

> 
> For gobject bindings, I have not yet found a simple solution to
> moving forward. For most WebIDL features we have simply been coding
> the gobject bindings generator so it does not try to generate code
> for functions that make use of them. For this new exception approach
> we have another challenge: Unlike the Objective-C bindings or the
> JavaScript bindings, the signature of the gobject binding functions
> is different when an exception is involved, because there is a
> GError** out argument for each of them. So unlike JavaScript or
> Objective-C, both of which use an exception system for the bindings
> which does not affect function signatures, the gobject bindings
> generator today depends on exception extended attributes to determine
> what the interface is to each binding function. This is a problem I
> must solve to move forward with the new exception model for our DOM
> and WebIDL without breaking gobject bindings.

The GObject DOM bindings are part of the public WebKitGTK+ API, which
means we never break the backwards API/ABI compatibility. We realized
how problematic is that for a code that is autogenerated. That's we
deiced to split the API into "stable" and "unstable". The main
different is that we don't guarantee any compatibility for the unstable
part, and we require the users to define a macro to be able to actually
use it. Any new method or object that is added the bindings goes to the
unstable API, so it can't break anything. The stable part is a subset
of the DOM API, pretty much the same to what you have currently frozen
for Objective-C, I think. Only changes to those existing methods can
actually break something. In most of the cases the API/ABI is broken
but the build isn't affected. We have a script run by the bots to
detect those cases and fixing them is usually trivial. Build breaks
happen even less often and are the actual problem. In this particular
case, I think the exception system change is a exceptional case and not
the rule, so we could just find a solution for this, instead of a
general solution for something that doesn't happen that often.

> 
> I see a few different options, maybe not all real practical ones:
> 
> Option 1) Freeze gobject bindings as we did the Objective-C ones;
> stop auto generating them. Add new bindings by hand as desired and
> needed. This has major benefit for people working on WebIDL features
> for the JavaScript bindings; we have a lot of work to do on those and
> we are not easily able to make the gobject bindings come along. There
> are all sorts of new WebIDL features that we cannot easily implement
> for gobject without considerable e

[webkit-dev] WebKit gobject bindings: Who is guiding their future?

[Darin Adler]

Hi folks.

You may have noticed the substantial improvements we’ve made to our WebIDL 
support over the last year.

Also, the last few days I’ve been working on one small exciting improvement to 
our JavaScript bindings. We can express exceptions as a special return value 
inside the DOM implementations, ExceptionOr, instead of using an 
ExceptionCode& out argument. This has many benefits; one of them is that we 
don’t need the [RaisesException] family of extended attributes to generate 
JavaScript bindings. Instead the bindings use C++ templates to generate 
exception-propagating code when needed based on function return types without 
having to specify anything in the IDL.

The first step in this direction is in 
>.

For Objective-C bindings, our approach is now that instead of trying to 
implement WebIDL features, we instead hand maintain a legacy set of bindings as 
we change the underlying DOM implementation. This works because we decided to 
“freeze” the bindings and no longer intend to automatically generate them or 
have them automatically track additions to the web platform. For WebKit at 
Apple, we consider the Objective-C bindings a part of the legacy WebKit, and 
for the modern WebKit API (WebKit2) we use different approaches inside injected 
bundles, such as dynamically bridging from Swift and Objective-C to JavaScript 
rather statically bridging to the DOM. Stability is more important than 
features for our Objective-C bindings; they are there largely for compatibility 
rather than being our favorite forward-looking API for manipulating webpage 
content.

For gobject bindings, I have not yet found a simple solution to moving forward. 
For most WebIDL features we have simply been coding the gobject bindings 
generator so it does not try to generate code for functions that make use of 
them. For this new exception approach we have another challenge: Unlike the 
Objective-C bindings or the JavaScript bindings, the signature of the gobject 
binding functions is different when an exception is involved, because there is 
a GError** out argument for each of them. So unlike JavaScript or Objective-C, 
both of which use an exception system for the bindings which does not affect 
function signatures, the gobject bindings generator today depends on exception 
extended attributes to determine what the interface is to each binding 
function. This is a problem I must solve to move forward with the new exception 
model for our DOM and WebIDL without breaking gobject bindings.

I see a few different options, maybe not all real practical ones:

Option 1) Freeze gobject bindings as we did the Objective-C ones; stop auto 
generating them. Add new bindings by hand as desired and needed. This has major 
benefit for people working on WebIDL features for the JavaScript bindings; we 
have a lot of work to do on those and we are not easily able to make the 
gobject bindings come along. There are all sorts of new WebIDL features that we 
cannot easily implement for gobject without considerable effort, such as enum 
and union types, various types of overloading and default argument values, 
setlike, the list goes on and on and this has been going on for months at least 
already. There’s a good reason we did this “freezing” for Objective-C and it 
seems likely to be worthwhile for gobject too. This will also let us get rid of 
the 88 places in the IDL files where we have gobject-binding-specific #if 
statements, many of which were originally added for Objective-C and probably 
have not all been carefully audited.

Option 2) Express the list of which functions have a GError** out argument as 
an explicit list of function names inside the gobject bindings generator and 
generate code accordingly. This is not all that farfetched given we already 
have .symbols files to help keep the set of gobject bindings functions stay 
stable, and there is already a list inside the bindings generator of functions 
that used to raise exceptions and therefore have a GError** out argument that 
is never used, showing that this issue is not a new one. Compared to (1) this 
is just a stopgap measure. It can keep existing functions working, but does not 
give us a clear path for what to do as we add more and more DOM APIs that don’t 
fit in with what the gobject binding code generator can do.

Option 3) Keep the extended attributes telling whether something raises 
exceptions in the IDL files as gobject-specific attributes that are ignored by 
the JavaScript bindings.

Are there other practical options?

I strongly prefer option 1, and I would like to hear from the people who are 
working to make the gobject bindings work well to get an idea of how they feel 
about this and how they’d like to proceed, before I decide what to do.

— Darin___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://list