On Sun, 2006-07-23 at 11:38 +0200, Roland Weber wrote:
> 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?
>
CookieSpecs' internal state may need to be altered on a per
request/response basis. Think of a list of valid date formats specified
in HttpParams at the HTTP method level. If we want all HTTP
requests/responses be served by just one CookieSpec instance, then
CookieSpecs must be stateless and configurable globally only. Stateful
CookieSpec on the other hand buy us some flexibility and ability to
configure CookieSpecs on a per host / method basis.
> > * 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.
>
Let us revisit this issue when porting the RFC2965 cookie spec to the
new API. Cookie2, which adds a number of new cookie attributes, may be a
pretty good test case.
>
>
> > * 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 does depend on HttpCore. So, we are free to add HTTP
request / response interceptors as we set fit.
> 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.
>
This is just a very first cut at the HttpCookie API redesign. Lots of
things are still bound to change. We may still do away with CookiePolicy
altogether, if it proves too inflexible.
Cheers,
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
