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/
signature.asc
Description: This is a digitally signed message part
