[webkit-gtk] WK2: Adapting the Policy Decision Framework for Geolocation

Mario Sanchez Prada msanchez at igalia.com
Tue Apr 3 02:26:14 PDT 2012

On Tue, 2012-04-03 at 08:59 +0200, Carlos Garcia Campos wrote:
> El lun, 02-04-2012 a las 15:42 -0700, Martin Robinson escribió:
> > I like the approach in option 1, but I think that we can scrap the
> > GObject interface with an abstract C++ class in the private data
> > portion of the WebKitPolicyDecision object. Since this issue is only
> > an implementation detail, I think we should avoid completely exposing
> > it in the API.
> It's not just an implementation detail, Mario is concerned of exposing a
> download method in the API for policy decisions where it doesn't make
> sense to download anything. His approach moves the download method down
> the hierarchy so that it can only be used with Navigation and Request
> policy decisions.

Yeah, exactly. For me it's not just an implementation detail, it's more
about what we want to expose to apps in the public API.

To be honest, I had already a hard time understanding why this
download() method was both in WebKitGTK+ [1] and WebKit2GTK+ APIs [2],
since it sounded strange to me that you could "use" and "ignore" a
'policy decision', but also "download" it :-).

However, I can see also the point of keeping consistency between
WebKitGTK+ and WebKit2GTK+ APIs, and so that would lean us towards
keeping the download() method here... but in that case I wonder whether
it wouldn't be perhaps better to accept that this "policy decision
framework" is just a wrapper for the internal Policy Clilent, and then
implement "geolocation permission requests" completely out of this
framework, as it's done in WebKitGTK+.

> > [...]
> > Here are the benefits I see to this approach:
> > 1. It's less code.
> > 2. The API does not bleed details of the implementation.
> I don't think the problem is a matter of using C or C++, this solution
> would be the same than the first one I proposed, but a bit more elegant
> using C++ internally instead of having both the listener and the
> geolocation request in WebKitPolicyDecisionPrivate.

It's basically the second option I proposed.

> As I said I'm fine with this solution, but it doesn't solve the
> problem Mario is worried about.

Exactly. And as I said before, I think I would prefer going with
implementing "geolocation permission requests" in a completely separated
way than going ahead with this approach, unless you both clearly say
that would not be the way to go (Carlos already said it, actually).

Perhaps we're just forcing things too much.



More information about the webkit-gtk mailing list