[WebKit-devel] AccessManager Integration

[Dawit A.]

Use this patch instead. It should compile without problems. It should be 
applied from kdelibs as it contains patches for kdelibs/kdewebkit and 
kdelibs/kio/kio/

On Wednesday 25 November 2009 12:27:05 Dawit A. wrote:
> 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_and_kdewebkit.patch
Type: text/x-patch
Size: 11305 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/webkit-devel/attachments/20091125/bee2fab8/attachment.patch