I have attached a patch of my own previous implementation minus unit tests (deft-52_alt.patch), which has been kicked into place and is for discussion only. Not at all near complete.
Ran through Michele's patch, and it works like a charm. A couple of comments and questions:
I really liked Michele's idea of storing the cookies as simply strings, and ditching any skeleton object. This needs us to provide a number of setter methods, though - there are currently seven, and that's without other properties liked "discard" and "max-age". The other implementation will return a Cookie object after a set of name/value pair; this is stored by HttpResponse and can be modified through accessors. All cookies are written during HttpResponse#flush. I created a simple example that set, expired and retrieved with both implementations and took the last two runs:
Requests per second: 14368.70 /sec (mean)
Requests per second: 14446.50 /sec (mean)
Requests per second: 14989.25 /sec (mean)
Requests per second: 14687.58 /sec (mean)
Michele's work is faster and straightforward, but the object allows for sanity checking. Does anybody have an opinion on which approach they would prefer? Michele, would you like to try and see what kind of difference you get?
Specific to Michele's work, I have some notes:
- I missed the "clearCookie(String)" method, as I was looking for "expireCookie(String)". Just me, or a better name?
- Would we change the void setter methods to String, to return what we created?
- When we decide what to do, there're unit tests and Javadoc to be written.