Am 05/02/2013 18:51, schrieb Hamish Morrison:
Recently I've been hacking on the services kit, with the intention of getting it cleaned up so it can be used for a network backend in the WebKit port.
Yay! :-)
There are a couple of parts of the BUrlRequest API that are bothering me. BUrlRequest tries to provide a protocol agnostic interface for setting request options: BUrlRequest::SetOption(int32 option, void* value) The option and value are passed through to the BUrlProtocolXYZ instance. This seems a little ugly to me, and requires the user to know which protocol was instantiated in order to set valid options. Why not just have some setters on BUrlRequest for common options (user/pw authentication, redirection settings, custom HTTP headers), and then specific BUrlProtocols can use or ignore these options as appropriate?
Setters for everything might not be flexible enough, but for most common uses they certainly make sense. I'm not too familiar with the services API to admit, but I think looking at how Qt and Java do it usually helps with the inspiration :-) For example, the QNetworkRequest/QNetworkReply API is relatively nice, and might be worth a look at.
The BUrlProtocol instance being used to handle the specifics of the protocol is exposed to the user, which seems unnecessary as it provides no more information than the BUrlRequest. Maybe the BUrlProtocol classes be kept private?
The only reason I could think of would be protocol specific functionality you would like enough to violate the layering :-) For example, in Java, you can get to a HttpConnection which exposes special API for its functionality, that is otherwise only available through a less nice generic interface. Maybe there is a golden middle way, though, at least Qt does not seem to reveal the protocol class :-)
BUrlProtocol currently counts both connection/processing errors and protocol errors (e.g. HTTP 404) as request failures. This seems a little confusing, because if a protocol error occurred there will still be a valid UrlResult available (maybe containing an error page). Perhaps some distinction should be made here?
Sure. I would not consider the services kit mature in any way yet -- if you feel changes make sense, even if they turn around every stone, now is the best time to do it, since it's not really used anywhere yet.
Bye, Axel.