hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [http-common] RFC: HttpEntity, HttpIncomingEntity, HttpOutgoingEntity revisited
Date Thu, 28 Apr 2005 09:03:17 GMT
Hi Roland

I guess I should have been more specific in my initial post.

My main point is that HttpEntity that cannot produce its content is
COMPLETELY useless unless cast to a more specific interface. Having to
cast HttpEntity interface EVERY TIME it is used results in a quite ugly
and IMO irritating code.

Likewise if HttpEntityEnclosingRequest interface is made to produce
an HttpOutpoingEntity on the client side, this interface is no longer
useable on the server, because the server expects an HttpIncomingEntity
instead. Inevitably one needs two interfaces
HttpIncomingEntityEnclosingRequest and
HttpOutgoingEntityEnclosingRequest to solve the problem. The same story
goes for the HttpResponse interface. One would also need two super
interfaces HttpIncomingResponse and HttpOutgoingResponse. For all these
interfaces one would need HttpMutable* counterparts. The situation gets
completely ridiculous, at least in my opinion, and we end up with a
classical over-designed API. 

The solution currently in place however imperfect gets the same job done
with just a few interfaces equally applicable on the server and the
client side. 

> So I would expect a protected getInputStream() in a base class, rather
> than a public one in the interface.

I would *really* like to avoid having to enforce a common base class for
HTTP entities

> My idea was to use a factory pattern for instantiating incoming
> entities:
> StringEntity se = (StringEntity) 
> response.getIncomingEntity(StringEntity.class)

We have long maintained a stance that HttpClient is a content agnostic
library. Anything that has to do with content processing should be built
on top of HttpClient and should not be a part of the library. We
certainly should not get ourselves into the MIME content business. I
personally would rather prefer a simple consumer pattern where various
HTTP content consumers simply retrieve the content from
HttpEntity#getContent as an InputStream, hence the motivation for moving
this functionality to the base interface

All these drivels aside I'll be happy to see a patch that keeps
HttpEntity/HttpIncomingEntity/HttpOutcomingEntity paradigm (which is
quite beautiful from the conceptual standpoint) and addresses the above
mentioned shortcomings. I just _personally_ do not see how this can be
done, at least at this point



On Thu, Apr 28, 2005 at 08:20:48AM +0200, Roland Weber wrote:
> Hi Oleg,
> Mike's note made me think about this again...
> > (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
> Do we need a public getInputStream() in the generic interfaces anyway?
> My idea was that the InputStream is used internally by the (incoming)
> entity to parse it's content, and that only a stream-type entity would
> provide "raw" access to it. So I would expect a protected getInputStream()
> in a base class, rather than a public one in the interface.
> > (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
> My motivation for distinguishing between incoming and outgoing entities
> was to keep the parsing and generating separate, although that sure is
> overkill for the many simple entity types.
> By moving one of the functionalities into the base interface, it becomes
> mandatory. And thinking of multipart MIME for which there are different
> parser implementations, I'd rather have the generation than the parsing
> mandatory.
> > 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.
> My idea was to use a factory pattern for instantiating incoming entities:
> StringEntity se = (StringEntity) 
> response.getIncomingEntity(StringEntity.class)
> whereas the outgoing entities have a generic writeTo(OutputStream). On the
> client side, entity enclosing requests would allow setting an outgoing 
> entity,
> and responses provide incoming entities. On the server, it's the requests
> that provide the incoming entity and the responses expect an outgoing 
> entity
> to be set. The opposite operations could either be forbidden, or they 
> could
> be implemented conditionally for "two-way" entities.
> So I'd keep the incoming and outgoing entities as distinct attributes
> in the base class for HttpMessage, rather than casting a single attribute
> to either side. Again, sorry for not having the time to look into the 
> code.
> cheers,
>   Roland

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

View raw message