[WebKit-devel] KDE WebKit status update [Remix]

[Dawit A.]

On Monday 12 October 2009 04:27:30 David Faure wrote:
> On Monday 12 October 2009, Michael Howell wrote:
> > On Sunday 11 October 2009 15:37:09 David Faure wrote:
> > > On Saturday 10 October 2009, Urs Wolfer wrote:
> > > > On Saturday 10 October 2009 17:10:20 Michael Howell wrote:
> > > > > On Saturday 10 October 2009 07:41:38 Urs Wolfer wrote:
> > > > > > QNetworkAccessManager is also used by others than the webkit
> > > > > > stuff in KDE [1]. I am not aware of a possible user of the Cookie
> > > > > > stuff though. Are you?
> > > >
> > > > Okay, I agree on this. What's about the name? KIO::CookieJar? David,
> > > > what do you think about this?
> > >
> > > How about KNetworkAccessManager::CookieJar?
> >
> > Do you mean KIO::AccessManager::CookieJar?
> 
> Ah sorry I forgot the actual name of the class currently in KIO.
> Yes, I meant KIO::AccessManager::CookieJar then.
> To make it clear that it only makes sense to use it together with
> KIO::AccessManager, not for the general case of "using KIO and wanting
>  cookies to work".

I disagree simply because

#1. Doing so will not prevent people from abusing the class even if it is 
public member of KIO::AccessManager . In other words, if they want to, they 
still can use it as a replacement of the standard method of accessing the 
cookiejar in KDE. 

#2. The use of QNetworkCookieJar does not depend on QNetworkAccessManager. It 
is actually the vise-versa. QNetworkAccessManager uses QNetworkCookieJar. So 
why should a re-implementation of such class create the reverse association ?

#3. If developers use the KDE APIs in their application to begin with, then 
there should actually be no reason to concern themselves with the cookiejar 
integration issue since it is all automagically taken care of for them through 
KIO. As such, they are not going to go looking for such a class ?

Instead how about simply naming the class KIO::NetworkCookieJar as I 
previously suggested, but then adding the code to the existing accessmanager.* 
files ? That way the intended use of the class should be just as obvious. Of 
course that is in addition to the intent of the class already being clearly 
documented...