hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <ROLWE...@de.ibm.com>
Subject Re: [http-common] RFC: HttpEntity, HttpIncomingEntity, HttpOutgoingEntity revisited
Date Thu, 28 Apr 2005 05:42:57 GMT
Hi Oleg,

sounds reasonable. Go ahead. Do you want
to add a method to HttpEntity for checking
whether a non-repeatable entity has already
been consumed?

I'm sorry that I currently don't have the time
to dig into the new code.


Oleg Kalnichevski <olegk@apache.org> wrote on 26.04.2005 11:05:36:

> 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 
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message