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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
