Hi
I can see that HttpResponse offers many more useful methods than Response does.
I'm wondering if the idea of having HttpResponse extending Response makes sense. I personally see it as a viable option.
Basically, HttpResponse in 98% is the specialization of Response.
Response gives absolutely everything that a client needs to know about the server response.
So if we had most of existing HttpResponse methods pushed down to Response except for setters and annotateEntity meant for client-side filters
then the existing client side code operating with Response (well - we do reuse Response in our version of client api) would stay operational.
Well - I'm thinking as I'm typing - we could easily use HttpResponse setters in server side filters too - we've had many cases where users wanted to
modify Response headers in custom server filters before Response has been written to OutputStream...
Which makes me ask: do we really need to have HttpResponse and Response ?
thanks, Sergey