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 <[email protected]> > 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
