[webkit-gtk] WK2: Adapting the Policy Decision Framework for Geolocation
Carlos Garcia Campos
cgarcia at igalia.com
Tue Apr 3 08:47:28 PDT 2012
El mar, 03-04-2012 a las 08:31 -0700, Martin Robinson escribió:
> On Tue, Apr 3, 2012 at 2:26 AM, Mario Sanchez Prada <msanchez at igalia.com> wrote:
> >> 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.
> It is true that a 'download' action exists for a new decision type
> that it doesn't make sense for. Consider that it already only ever
> makes sense for WebkitResponsePolicyDecisions. Take a look at the
> documentation in WebKitWebView.h. Right now 'download' is available
> for all decisions, because this is the way the C API works.
That doesn't mean it's correct.
> If you insist that it must only be available for the one decision
> type, then why not consider this counter-proposal:
> 1. Accept my proposal above, without the 'download' method.
> 2. Add a webkit_response_policy_decision_download method to
Isn't it possible to use download for navigation decisions when the
action is link clicked?
> > To be honest, I had already a hard time understanding why this
> > download() method was both in WebKitGTK+  and WebKit2GTK+ APIs ,
> > since it sounded strange to me that you could "use" and "ignore" a
> > 'policy decision', but also "download" it :-).
> The answer to this is simple: being able to 'download' is an important usecase.
> > 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 is where you lose me. It is possible that geolocation requests do
> not fit into the policy decision framework, but not because of this
> issue. I say this because the issue already existed with
> WebKitNavigationPolicyDecision, WebKitNavigationPolicyDecision, the C
> API and WebKit1. It's not a new thing. :)
Yes, it's not a new thing, it's the first thing I said when I replied
Mario, but Mario raised the existing issue and he is proposing ways to
solve it while adding the geolocation API.
I agree that it's not enough reason to not try to integrate the
geolocation policy API into the existing policy-decision framework.
Carlos Garcia Campos
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the webkit-gtk