mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [AsyncWeb] Client redesign
Date Sun, 10 Feb 2008 19:40:23 GMT

On Feb 10, 2008, at 10:05 AM, David M. Lloyd wrote:

>
>> I think that this bit can be, and is, handled with URLs.  I don't  
>> see the advantage of adding complexity to the metaphor and, hence,  
>> the API.
>
> This isn't a metaphor, it's an API.  Using a metaphor to help  
> conceptualize
> what you're trying to accomplish can be helpful, but there's no  
> point in
> carrying it any farther than that.  Once you start rejecting an idea  
> because
> it doesn't fit you metaphor, you've stepped over that line.  To  
> properly
> design a useful API, the only thing that matters are the functional
> requirements (i.e., what usecases must the API support?).

We shall agreed to disagree here.

I fully understand the need for compelling use cases to drive the  
API.  A clean metaphor means a clean API.  A great metaphor helps  
users quickly and accurately assimilate an API.  Slavishly extending  
an API in an ad hoc manner, and I'm not claiming that this is what you  
are doing, to support use cases more often than not leads to a  
Byzantine API that is hard to use.  A good metaphor is very important.

> In any case, yes, allowing the user to specify a URI to both a  
> connection
> and a request would be sufficient to solve this problem.  The key  
> difference
> that I want to point out is, the request URI should not be required  
> to be
> relative to the connection URI; consequently, the connection URI  
> should not
> have a path, query, or fragment part (since the URI is used only for  
> the
> purposes of extracting the scheme, host, and port).  In addition,  
> the user-
> info part should be part of the request URI (since it can change on a
> per-request basis), not the connection URI.
>
> 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.


I see and take your point.  It is six of one and half a dozen of  
another.  What I'm confused about is why we need to initially specify  
anything outside of the actual request.  What problem are we trying to  
solve?  Maybe I'm misunderstanding what you are espousing so let me  
put it in my own words and you tell me if it's accurate.  Please  
ignore the argument of using URIs or discrete parameters for me moment  
because I think that they are obscuring my real concern.

HttpClient client = HttpClientFactory.create(baseURI);
client.send("/foo?pet=cat")

If this is accurate, I don't understand the need for the baseURI.   
Maybe this is a MINA convention?


Regards,
Alan





Mime
View raw message