[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: [PATCH] KIO::SlaveBase and the event loop
From:       "Roland Harnau" <truthandprogress () googlemail ! com>
Date:       2008-07-27 19:13:30
Message-ID: 476f836a0807271213x58e4ad6aka29425aa4cb177a3 () mail ! gmail ! com
[Download RAW message or body]

2008/7/22, Thiago Macieira <thiago@kde.org>:
> On Tuesday 22 July 2008 12:12:05 Roland Harnau wrote:
>> 2008/7/21, Thiago Macieira <thiago@kde.org>:
>> > I might point out that there's another HTTP implementation already
>> > loaded in KDE applications, which is the one in QtNetwork (no, not QHttp). If
>> > there's interest, we can make the class public.
>>
>> QHttpNetworkConnection?
>
> Yes. That's the one.
>
> It's the backend for QNetworkAccessManager, which is what QtWebKit uses.
> It's  a full HTTP/1.1 implementation.

I have eventually looked at it and I like the way it handles HTTP,
especially the maximal two persistent connections per host as
recommended by the HTTP/1.1 specification and the fact that almost
everything is done in a non-blocking event-driven fashion. Otherwise
it would take away some flexibility from KDE, e.g. QSslSocket is
hard-coded, so DNS caching (perhaps not so important if there are only
two connections per host) and SSL session support are not possible
anymore just as pipelining. To my surprise the QtNetwork module even
contains a file backend, so the whole infrastructure around
QNetworkAccessManager pretty much looks like a in-process version of
KIO.

The KHTML part  uses KIO mainly  with KIO::get and KIO::put and
therefore relies on KIO::TransferJob. I currently think about
replacing it with a direct subclass of KIO::Job which has essentially
the same interface as KIO::TransferJob but uses internally the
QtNetwork module instead of slaves to see if it really improves page
loading.


Roland
[prev in list] [next in list] [prev in thread] [next in thread]