mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 이희승 "(Trustin Lee)" <trus...@gmail.com>
Subject Re: [AsyncWeb] Client redesign
Date Sun, 10 Feb 2008 07:30:01 GMT
First off, I agree with what's under consensus so far in this thread.
Great to see more people get involved! :)

2008-02-09 (토), 17:01 -0800, Alan D. Cabrera 쓰시길:
> On Feb 9, 2008, at 3:56 PM, Mike Heath wrote:
> 
> > Alan D. Cabrera wrote:
> >
> > <snip>
> >
> >>> That's a good thought.  The reason that the URL was originally put  
> >>> in the
> >>> HttpClient constructor (as well as the request) was to allow the
> >>> management
> >>> of connections to be separated from the URL request.   
> >>> Realistically, a
> >>> URL
> >>> could be dropped in favor of discrete scheme/hostname/port  
> >>> parameters on
> >>> an connection object.  Though it's not always desirable to do  
> >>> this, so
> >>> specifying and maintaining a physical connection should be an  
> >>> optional
> >>> kind
> >>> of thing to do.
> >>
> >> Not sure why one needs to specify the URL so far in advance.
> >
> > I like the idea of specifying a base URI for the HttpClient.  So you  
> > use
> > a base URI of something like "http://somedomain.foo" and subsequent
> > requests could then do something like get("/bar") which would do a GET
> > on "http://somedomain.foo/bar".
> >
> > This would require further abstraction than what AHC has to offer  
> > currently.
> 
> 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.

You mean the java.net.URL class?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message