As you can probably see from recent blogs, lots of new features are being merged into the mainline Qt (what will become Qt 4.4.0). The latest big one is the Network Access API we’ve been developing for the past few months. It’s in today’s snapshot, so you can try it out already. I’d like to thank Marius Monsen, Prasanth, Lars, Andreas, Simon and everyone else who contributed (even if they just contributed opinions).

It’s also one of the big pieces necessary for WebKit: what’s the use of a browser engine if you can’t download anything off the Internet? And another big new feature: an entirely new HTTP stack, written from the scratch to be fully HTTP/1.1 compatible. At this point in time, we’re throwing random junk and real HTTP replies into it to see how it handles broken servers out there (and broken applications too, like trying to download HTTP off the wrong port).

The design is fairly simple. And if it gives you a sensation of déjà vu, it may be because we designed it to be similar to KIO. And now you’re going to ask me: is it supposed to replace KIO? Well, definitely not, at least not in Qt 4.4: KIO does a lot more than file transfers. It also does file management operations (such as copying, moving, deleting, etc.), which is not part of our design here.

But enough of talking, let’s see some code. The following is a full application that downloads the contents of the first argument:

int main(int argc, char **argv)
{
    QCoreApplication app(argc, argv);

    QNetworkAccessManager manager;
    QNetworkReply *reply = manager.get(QUrl::fromEncoded(argv[1]));
    app.connect(reply, SIGNAL(finished()), SLOT(quit()));
    app.exec();
    qDebug() < < reply->readAll();
}

QNetworkAccessManager is the central class in the design. It holds some configuration (proxy, defaults, etc.) and some internal state. It takes one QNetworkRequest object and an operation (based on HTTP operations: get, post, put, head) and returns a QNetworkReply object.

QNetworkRequest is a simple, value-based implicitly-shared class that holds a URL and some meta-data: HTTP headers and extra attributes. It also does parsing of some tricky HTTP headers for you, so you don’t have to worry about getting the HTTP dates right.

Finally, QNetworkReply is an abstract QIODevice-based class. It’s open for reading by the time you get it, which means it will emit readyRead() whenever data is available for reading. Unlike KIO::TransferJob, if you don’t react to the signal, you won’t lose the data.

The next phase now is to make WebKit use this new infrastructure. The API will probably have a simple setManager() function that takes a QNetworkAccessManager object. When it needs more data from the network, it’ll simply call get() there.

We’ve also designed it to be extensible. You’ll be able to write your own QNetworkAccessManager class, that returns your own QNetworkReply objects and/or implements your application’s own network and security policies.

We’re interested in the feedback you can give us. The team and I are available for questions in the qt4-preview-feedback mailing list.