hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <mbe...@gmail.com>
Subject Re: [http-common] RFC: HttpEntity, HttpIncomingEntity, HttpOutgoingEntity revisited
Date Wed, 27 Apr 2005 03:15:32 GMT
Casting back and forth can definitely be annoying.  A solution that
fixes this problem would certainly be good.  My only concern is that
we maintain the ability to write directly to the output stream.  The
changes you recently checked in seems to preserve this.

The only other option that comes to mind would be reverse the current
situation and move writeTo(OutputStream) to HttpEntity and
getContent() to HttpStreamableEntity (or somewhere appropriate).  My
thinking here is that all entity types can be written to an output
stream, but not all can produce (at least easily) an input stream.

Mike

On 4/26/05, Oleg Kalnichevski <olegk@apache.org> wrote:
> Folks,
> 
> After having spent some time working on the http-common API I would like
> to propose some changes to HttpEntity, HttpIncomingEntity &
> HttpOutgoingEntity interfaces.
> 
> Presently HttpResponse and HttpEntityEnclosingRequest return a generic
> HttpEntity interface in order to be useable on both client and server
> side. From the design purism perspective this is probably quite okay. At
> the same time in practical terms this approach requires HttpEntity to be
> cast to either HttpIncomingEntity or HttpOutgoingEntity all the time to be
> of any use. All these castings get quite irritating quite fast.
> 
> (1) Fundamentally the distinction between HttpIncomingEntity and
> HttpOutgoingEntity behaviors is not necessary
> 
> (2) HttpIncomingEntity interface can be gotten rid of. After all it is
> perfectly reasonable for any generic entity to be able produce its
> content. getInputStream method gets moved to HttpEntity
> 
> (3) Rename HttpOutgoingEntity to HttpStreamableEntity. As far as I am
> concerned ability to stream itself is optional behavior for an entity
> (akin to HttpEntityEnclosingRequest) which should be treated as such
> 
> This approach may create some problems for non-repeatable entities such
> as InputStreamEntity but they can be resolved by maintaining the object
> state and refusing to stream out the content if it has already been
> consumed through getInputStream method. I feel this is a small price to
> pay for a much less irritating API
> 
> What you think?
> 
> Oleg
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message