hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: [HttpComponents] HttpCookie API redesign
Date Sun, 23 Jul 2006 09:38:10 GMT
Hi Oleg,

I finally found some time to look at the code.

> * CookieSpecs are now stateful and are instantiated using an object
> factory

The factory is an improvement over the Class object used in the old API.
But I still don't get why there is this indirection at all. Why don't
we register CookieSpec objects, instead of creating new ones all the time?

> * We were initially planning to make Cookie an interface. I am no longer
> sure this makes sense. The Cookie class does not have any processing
> logic left in it and now is merely a value object. There seems nothing
> to be gained from making Cookie abstract. Please let me know if you
> agree.

It is just a general feeling I have that classes instead of interfaces
in an API might, at some point in the future, come back to bite you.
But I don't insist on introducing an interface here. If instantiation
of the class is based on a factory concept, so that developers can
specify their own subclass to be instantiated, that's fine by me. I'm
thinking of things like serialization here.

> * HttpCookie requires Java 1.3 and HttpCore only. It has no dependency
> on any code in HttpClient outside org.apache.http.cookie package.

So I take it that there won't be a response interceptor for parsing
cookies and storing them in a state in HttpCookie? Or will we put that
in a subpackage ("mgmt"? "store"? "box"?) and tell people that only
the subpackage has a dependency on HttpCore?

> * HttpCookie code has a very high test coverage (98-100%). I succeeded
> in reusing almost all existing test cases from HttpClient 3.x branch.

Impressive. Congratulations.

The CookiePolicy object is global. That means we can't configure
different sets of cookie policies for different parts of an application.
It's not likely to be needed, and there is a workaround by prefixing
the IDs used for registering, so this shouldn't be a problem. It just
jumped into my mind right now, so I thought I'd rather mention it.


To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org

View raw message