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

[Dawit A.]

On Tuesday 13 October 2009 11:30:19 Michael Howell wrote:
> On Tuesday 13 October 2009 06:47:01 Dawit A. wrote:
> > #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.
> 
> Same with KIO::AccessManager. In fact, I personally don't see a problem
>  with that, if you like the API better or if you're offering Qt-only
>  builds.

I think you made the same point here ? It does not matter where the class is 
placed, you cannot stop people from abusing it if they *want* to. And as  I 
mentioned in reason #3, if the application began itself as a KDE application, 
the developer would not be concerned with cookiejar integration in the first 
place because it is automagically taken care of ; so the dicussion here should 
reovlves around those that want integration because they cannot directly use 
the KDE API for whatever reason...

> > #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 ?
> 
> Maybe in Qt, but in KIO::AccessManager, that's actually not the case. All
> KIO::AccessManager does is wrap the KIO calls, which handle cookies
> implicitly. If you want to use KIO::AccessManager, you may not need to use
>  the CookieJar, but if you're using the CookieJar, it's because you're also
>  using AccessManager.

Not really... A cookie management application would have no use for the 
AccessManager. The same if you want to integrate with the platform specific 
cookie manager whenever possible  (casuse the Qt version is useless), but want 
to stick with QHttp. 

> > #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...
> 
> I actually wouldn't mind that name, except that KIO::AccessManager doesn't
> have the "Network" prefix. KIO::CookieJar would be nice, except that it
>  doesn't imply that it's a wrapper. OTOH, neither does
>  KIO::AccessManager...

Well IMO if we want to really make the intent of these classes clear, they 
should be put under a clear namespace, e.g. KDENetworkIntegration.

namespace KIO
{

namespace KDENetworkIntegration
{

class AccessManager : public QNetworkAccessManager
{
...
};

class CookieJar : public QNetworkCookieJar
{
...
};

} // namespace KDENetworkIntegration

// TODO: Remove KDE 5. BC
typedef KDENetworkIntegration::AccessManager AccessManager 

} // namespace KIO

I rather prefer that nested namespace because the sole purpose of the second 
namespace is to indicate the intent of these classes. It also removes the 
classes out of the toplevel KIO namespace... Anyhow, I really do not have any 
preference how this is handled so long as the class is placed in the correct 
location in the end...