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
