hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject [http-common] RFC: HttpEntity, HttpIncomingEntity, HttpOutgoingEntity revisited
Date Tue, 26 Apr 2005 09:05:36 GMT
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


Mime
View raw message