David M. Lloyd wrote:
The limitation on what would be allowed on a connection URI is the reason
that I suggested earlier that the API could accept discrete scheme,
hostname,
and port parts - since the rest of the URI is not useful anyway. But since
either method satisfies the requirements (it's just a question of
aesthetics
at this point), I'm satisfied either way.
More arguments both ways:
Requiring hostname and port instead of an URI for the connection makes
the user of the connection do URI parsing, which is somewhat ugly, and
quite repetitive. For the casual user, passing in the URI and letting
the library handle the ugly bits would be easier. However, parsing the
URI into hostname and port in the connection adds failure modes to the
connection, and requires the library to decide what to do in ambiguous
cases (is it actually specified somewhere that port for an HTTP URI is
80 if not specified in the URI, for example?).
Of course, the casual user probably doesn't care about connection
pooling, and possibly not even about pipelining and keep-alive, he just
wants a component that takes an HttpRequest, does some magic and gets an
HttpResponse back to the callback he gave to the component.
