[haiku-development] Re: Services Kit API questions

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 05 Feb 2013 20:24:08 +0100

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.


Other related posts: