On 10/31/2011 06:09 PM, Sergey Beryozkin wrote:
> 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
I think that buffer entity is useful in cases when you don't want to deal with th content but need to make sure you have
it all - e.g. caching. But as I said, we'll see. There are always multiple paths to the goal, this applies to caching too.
Marek
>
> Sergey