mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tuure Laurinolli <tuure.laurino...@indagon.com>
Subject Re: [AsyncWeb] Client redesign
Date Sun, 10 Feb 2008 19:09:23 GMT
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.

Mime
View raw message