You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <ht...@dubioso.net> on 2006/02/03 17:35:47 UTC

connected entities

Hi folks,

I should be able to spend a few hours with coding this week-end. I'd
like to tackle some details I noticed while discussing "entities and
connections" with Oleg, and while working on http-async:

1. In order to keep a connection alive even if the application has not
read the response entity completely, on needs to call InputStream.close()
on the input stream returned by HttpEntity.getContent(). If entities are
layered, calling getContent() might trigger the creation of wrapping
input streams, just to close them immediately afterwards. If an entity
is not repeatable and has been read completely, this might even trigger
an exception.

2. HttpClientConnection.receiveResponseEntity initializes a response
object with an entity, but there is no way of telling whether that
entity depends on the connection, or whether it is already buffered
completely in memory. The DefaultHttpClientConnection will always return
an entity that depends on the connection, but there might be others.
Also, response postprocessing might replace a streamed entity with a
buffered one.

3. ByteArrayEntity and StringEntity are outgoing entities only. There
is no constructor or factory method to have them read and buffer another
(incoming) entity like the BasicHttpEntity. Most of the code to do this
is already available in class EntityUtil. This is rather cosmetic.


The idea I have about 1 and 2 is to add two methods to the HttpEntity
interface (method names subject to change):

public void disconnect();
public boolean isConnected();

If you've got helpful suggestions - or objections - I wouldn't mind
reading them before I start coding. There's a snooker broadcast this
evening, so I probably won't start until tomorrow ;-)

cheers,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Re: connected entities

Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,

>>If possible consider using an optional marker interface to provide this
>>functionality
>>
>>interface DetachableHttpEntity extends HttpEntity {
>>
>>  void detach();
>>  boolean isConnected();
>>
>>} 
> 
> 
> Thanks, that is just the kind of suggestion I was hoping for.
> I'll think it over thoroughly.

I've thought it over.
I've thought about what entities would need to implement the new interface.
I've thought about calling the interface IncomingHttpEntity, because those
are the entities that would need to implement it.
At that point, I dropped the idea :-)

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Re: connected entities

Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,

> If possible consider using an optional marker interface to provide this
> functionality
> 
> interface DetachableHttpEntity extends HttpEntity {
> 
>   void detach();
>   boolean isConnected();
> 
> } 

Thanks, that is just the kind of suggestion I was hoping for.
I'll think it over thoroughly.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Re: connected entities

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2006-02-03 at 17:35 +0100, Roland Weber wrote:
> Hi folks,
> 
> I should be able to spend a few hours with coding this week-end. I'd
> like to tackle some details I noticed while discussing "entities and
> connections" with Oleg, and while working on http-async:
> 
> 1. In order to keep a connection alive even if the application has not
> read the response entity completely, on needs to call InputStream.close()
> on the input stream returned by HttpEntity.getContent(). If entities are
> layered, calling getContent() might trigger the creation of wrapping
> input streams, just to close them immediately afterwards. If an entity
> is not repeatable and has been read completely, this might even trigger
> an exception.
> 
> 2. HttpClientConnection.receiveResponseEntity initializes a response
> object with an entity, but there is no way of telling whether that
> entity depends on the connection, or whether it is already buffered
> completely in memory. The DefaultHttpClientConnection will always return
> an entity that depends on the connection, but there might be others.
> Also, response postprocessing might replace a streamed entity with a
> buffered one.
> 
> 3. ByteArrayEntity and StringEntity are outgoing entities only. There
> is no constructor or factory method to have them read and buffer another
> (incoming) entity like the BasicHttpEntity. Most of the code to do this
> is already available in class EntityUtil. This is rather cosmetic.
> 
> 
> The idea I have about 1 and 2 is to add two methods to the HttpEntity
> interface (method names subject to change):
> 
> public void disconnect();
> public boolean isConnected();
> 
> If you've got helpful suggestions - or objections - I wouldn't mind
> reading them before I start coding. There's a snooker broadcast this
> evening, so I probably won't start until tomorrow ;-)
> 

Roland,
If possible consider using an optional marker interface to provide this
functionality

interface DetachableHttpEntity extends HttpEntity {

  void detach();
  boolean isConnected();

} 

or some such thing. I would prefer to avoid overloading HttpEntity
interface with two many methods, if not absolutely necessary. 

Otherwise, hack away

Cheers,

Oleg

> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org