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

[Martin Robinson]

On Mon, Apr 2, 2012 at 2:55 AM, Carlos Garcia Campos <cgarcia at igalia.com> wrote:
> Geolocation request has only accept/reject, so I don't think it's that
> different, we could handle it with a single policy framework using
> current decide-policy signal, so I would avoid option 2 if possible. And
> regarding 1 and 3, either one is fine with me, but maybe 1 would be
> better in the future if more policy decisions are added.

>> Problem is that, as far as I know, Martin's preferred order is exactly
>> the opposite (3 -> 2 -> 1) so we have a conflict here that must be
>> resolved somehow :-
>
> It would be great to hear more opinions then.

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. The creation of the WebKitFramePolicyDecision class is
an artificial result of this implementation detail. I'm not sure if
makes sense either, since geolocation requests are also associated
with frames. Sometimes naming problems point to real design problems.

Here's a more concrete explanation of what I'm suggesting with the
caveat that the names I'm choosing are terrible. :)

class PolicyDecisionDecisionListener {
public:
    void accept() = 0;
    void reject() = 0;
    void download() = 0;
}

class CAPIPolicyDecisionListener {
private:
   WKRetainPtr<WKFramePolicyListenerRef> m_listener;

public:
    void accept() {
        WKFramePolicyListenerUse(m_listener.get());
    }
  ...etc...
}

class GeolocationPolicyDecisionListener {
private:
    WKRetainPtr<WKGeolocationPermissionRequestRef> m_request;
public:
    void accept() {
       WKGeolocationPermissionRequestAllow(m_request.get());
    }
  ...etc...
}

In WebKitPolicyDecision.cpp:
struct _WebKitPolicyDecisionPrivate {
    OwnPtr<PolicyDecisionDecisionListener> listener;
    bool madePolicyDecision;
};

Here are the benefits I see to this approach:
1. It's less code.
2. The API does not bleed details of the implementation.

--Martin