Http client API

[Vasiliy Baranov]

On 17.08.2012 14:30, Michael McMahon wrote:
> On 09/08/12 19:15, Chris Hegarty wrote:
>> Michael,
>>
>> Looking good, some comments.
>>
>> 1) Why the use of CookieManager, rather than CookieHandler? I would
>> expect that CookieHandler would be a cleaner API
>>
>
> CookieHandler is a very low level API, which doesn't offer much
> functionality
> beyond managing the cookies yourself, which is what you would have to
> do, if there
> were no cookie capabilities in the http api. So, I don't know what we
> would gain from using it.
>
> While CookieManager isn't perfect (and we'd like to suggest a few
> improvements)
> it is a higher level API that does take care of cookie management with
> some common
> policies pre-defined.

java.net.CookieHandler is an abstract class, almost an interface, that 
represents everything an HTTP client needs to manage cookies. 
java.net.CookieManager is a concrete implementation of 
java.net.CookieHandler. At least that is the case in the current 
java.net.* design.

That said, shouldn't new HttpClient depend on the more abstract 
java.net.CookieHandler, rather than the more concrete 
java.net.CookieManager, for the sake of API cleanness and extensibility? 
If one prefers java.net.CookieManager over java.net.CookieHandler, it is 
possible to use the former everywhere where the latter is expected, but 
not the other way around.

As a side note, in the plugin environment, it might be more natural and 
less invasive to interface the browser cookie store via 
java.net.CookieHandler rather than java.net.CookieManager. FWIW, the 
current plug-in implementation, 
com.sun.deploy.net.cookie.DeployCookieSelector, does extend 
java.net.CookieHandler.

Just my two cents.

Thank you,
-- Vasiliy