Online Accounts, QtWebKit and Mir

[Bruno Girin]

On 19/03/13 12:51, Alberto Mardegan wrote:
> [...]
>
> As far as I can see it, these are the possibilities:
>
> 1) Implement the per-view cookie jar in WebKit2. This is the best end
> result, but the hardest to achieve -- at least for a non WekBit expert
> like me: it involves digging deep into WebKit code and, given all the
> big stakeholders involved, passing through the code reviews could take ages.
>
> 2) Same as above, but while the reviews are in progress, apply the patch
> to QtWebKit's Ubuntu packages. The longer the review process takes, the
> more painful this solution will be.
>
> 3) Implement QtQuick 2.0 bindings for WebKit*1*, and keep them as a
> separate module. I did this already, and it's more or less working [1].
> This can link against an unmodified libQt5WebKit.so, but in order to
> build the module we need to use some private QtWebKit headers -- and
> since these headers are generated during the build, it practically means
> that we need to have the QtWebKit source tree available in order to
> build this.
>
> 4) Like #3, but move the module as an Ubuntu patch for QtWebKit. This is
> far less dangerous than #2, because we are not modifying the QtWebKit
> build, just adding a very small extra .so (which we might drop in the
> future).
>
> 5) Like #4, but submit the code upstream. As you can read from the links
> above, the QtWebKit developers are not very fond of receiving more
> WebKit1-based code. Still, it might be possible to move both the QtQuick
> 2.0 module and the QtWebKitWidgets modules out of the tree by working on
> a common interface, so maybe this approach might be well received.

It looks like #1 is your strategic option, #2 is the strategic option
with a provision for decoupling from the review process, #3, #4 and #5
are variations on the tactical option.

I'd say #1 is the one to aim for but you need to remove the dependency
on the review process. #2 is not a good way to do this because of the
potential pain involved. You can de-couple the dependency by having one
of the tactical options as a fallback. Out of the tactical options, #4
seems the best one as it is safer than #3 and won't meet the same
(justified) resistance from upstream as #5.

So what I would do is:
- Implement #4 as your solution that works today,
- Then implement #1 and try to land it in time. If it can't land in
time, aim to deliver it in the next cycle as a replacement for #4.

As long as you communicate clearly that #4 is tactical, only there to
get you sorted for now and that your aim is #1, that should be a
solution that satisfies upstream too.

My £0.02

Bruno