On 31/10/11 16:59, Sergey Beryozkin wrote:
> On 26/10/11 15:33, Marek Potociar wrote:
>>
>>
>> On 10/16/2011 05:58 PM, Sergey Beryozkin wrote:
>>> Looks great, especially having a single Response entity.
>>>
>>> I'd propose to drop Response.bufferEntity() as it has no real use on
>>> the server side, and on the client side, when one
>>> really needs to delay processing a response, one simply can do
>>> Response.getEntity(...) and keep whatever the result is
>>> until later.
>>
>> Get entity is not guaranteed to buffer the entity (e.g. if it returns
>> a stream). But I will put a "probation" on the
>> bufferEntity and if we see that it's really not used in our impls
>> later we would drop it. How about that?
>>
>
> Sounds OK
>
A follow-up comment: having bufferEntity() means we should clarify what
happens with a buffered entity after bufferEntity() -> getEntity sequences
As I said, buffering an entity means a user wants to deal with Response
'out-of-band' - which can be easily achieved without having such a
dedicated method as bufferEntity() - but I'll keep my OK for possibly
dropping this method if it is not used
Sergey