As I just wrote, the idea is really to extend Response API. The reason for another class was that adding methods to a Response interface would break BW compatibility.
Marek
On 12. 8. 2011, at 11:16, Sergey Beryozkin wrote:
> 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