[webkit-dev] No getters for iconURL/title/body in Notification.idl

[Xan Lopez]

On Fri, Jul 1, 2011 at 8:17 PM, John Gregg <johnnyg at google.com> wrote:
> The data parameters are certainly needed by the UA to show the notification,
> but it seems like you're suggesting they need to be exposed as part of the
> Notification API (i.e., to web pages).  I don't see why that would be
> necessary.
> WebCore has a Notification object in C++ which does provide access to the
> fields, and which is passed up through the NotificationPresenter interface
> implemented in the ChromeClient.  That's how Chromium does it -- would it
> not work for GTK?

There's several things there.

- Indeed we'd use this WebCore Notification object, same than
Chromium. The problem is that this object doubles as the
representation of whatever is in the spec we follow (usually the DOM
spec, not in this case but close enough) and it also has extra things
useful for the UA, as we are discussing.

- In the normal case we just let our bindings generate automatically a
GObject wrapper for the core object, but since this is generated from
the IDL it would lack the needed accessors.

- You say that you don't see any need to let binding users access that
information, in that case our version of the DOM object probably
shouldn't allow that either.

- In that case we can either subclass it and add what we need, or just
not use the DOM objects in this case. The problem with the latter is
that we'd need to reimplement portions of the expected DOM interfaces
in the new class we'd do, so it seems a bit pointless to do so, and
that we'd expose two different versions of the object in different
scenarios (for instance, createNotification would create something
different than what you'd receive from the WebKit API in some cases).

In any case, I guess the obvious answer is: why is it not interesting
for the web page to access the parameters passed to the object when
it's constructed? Since it will generally be constructed from within
the page itself (unless I'm totally wrong), it seems reasonable.

Cheers,

Xan