[WebKit-devel] AccessManager Integration

[Dawit A.]

On Wednesday 25 November 2009 05:39:14 Andrea Diamantini wrote:
> I'm sorry my comments and reviews usually arrive "out-of-time", but I
>  really have poor free time in this period..

Yes, you are very late because all of this stuff was in kdereview for a couple 
of weeks. ;-) However, it is better to fix this stuff now before it is released 
because we have to deal with BC after it is released. We just need to make 
these changes before the hard freeze cutoff today...

> I'd like to debate here about the decision of providing a "private"
> implementation of KIO::AccessManager in kdewebkit.
> This morning I reviewed all commits and ml discussions about and I really
> didn't understand (yet) this decision.

The implementation was done that way because I never wanted to touch 
KIO::AccessManager at the time I started working on kdewebkit  because it was 
already a public API. That is it. But obviously that is not a good enough 
reason not to improve things...

> What's the gain in hiding the accessmanager? I fear nothing. In example I
>  need to support some custom protocol implementation (abp: , rekonq: ,
>  about: schemes). And I need to customize the accessmanager::createRequest
>  method for. Moreover applications and libs just using customized
>  KIO::AccessManager (plasma, kget/libbtcore, khns3 and obviously kdewebkit
>  the most notable ones) so having a proper API to access metadata can be
>  useful for all.

Though the points you raise here are very valid points, I do not understand 
why you need to re-implement ::createRequest to handle custom protocols. Is 
not re-implementing QWebPage::acceptNavigationRequest be suffficient for you ?

> Moreover cookies, from what I know, are http not just browsers related, so
>  I think (k)cookiejar integration should be enabled by default there.
> 
> This way, we can provide a general KIO::AccessManager in kdewebkit (or
>  enable it by default with a bool enable in webpage ctor, the same way
>  kwebview does with kwebpage) letting all users to customize it as they
>  like (and easily implement adfilters, custom protocol handling and so on).

Well you have very valid points and I agree the cookiejar integration code as 
well as the meta data access functions should be moved into KIO::AccessManager 
proper. That was there is no need for the private re-implementation class. And 
I can remove the the KWebPage::authorizedRequest virtual member function in 
KWePage because people can simply re-implement KIO::AccessManager to do their 
own filtering/custom protocol handling as they wish.

Anyhow, here is a patch to accomplish the above. If someone can test whether 
it compiles vs trunk, then it can be committed and the stuff removed from 
kdelibs/kdewebkit...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kio_accessmanager.patch
Type: text/x-patch
Size: 5171 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/webkit-devel/attachments/20091125/564f83f9/attachment.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kdewebkit.patch
Type: text/x-patch
Size: 5082 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/webkit-devel/attachments/20091125/564f83f9/attachment-0001.patch