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

[Carlos Garcia Campos]

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

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+ [1] and WebKit2GTK+ APIs [2],
> > 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
http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.webkit.org/pipermail/webkit-gtk/attachments/20120403/f53049b5/attachment.bin>