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 Sun, 01 May 2005 12:02:08 GMT

How do you feel about moving  writeTo(OutputStream) method from
HttpStreamableEntity (former HttpOutgoingEntity) to HttpEntity interface
and removing HttpStreamableEntity interface at all?


On Fri, 2005-04-29 at 11:50 +0200, Roland Weber wrote:
> Hi Oleg,
> > > ifce EntityEnclosingMessage {
> > >   setOgEntity(HttpOgEntity)
> > >   HttpIcEntity getIcEntity(Class what)
> > > }
> > 
> > Unfortunately I do not think this solves the problem completely. It is
> > necessary to be able to set HttpIncomingEntity when assembling the
> > incoming request on the server. Likewise, it is necessary to be able to
> > have access to the HttpOutcomingEntity when streaming out the request
> > body on the client side. Effectively the interface would probably have
> > to be
> > 
> > ifce EntityEnclosingMessage {
> >   setOgEntity(HttpOgEntity)
> >   setIcEntity(HttpInEntity)
> >   HttpIcEntity getIcEntity(Class what)
> >   HttpOgEntity getOgEntity()
> > }
> I agree that getOgEntity() is required. I had something in mind about a
> protected accessor, but that would create a dependency on a particular
> implementation class.
> I don't see the need to set an IcEntity though. The first one who needs
> to access the message body specifies the class/interface of the IcEntity.
> No need to set it.
> > I am also not in favor of forcing EntityEnclosingMessage impls to know
> > how to produce entities of different types. This coupling is unjustified
> > IMO.
> I agree. A factory - or alternative solution for instantiating entities -
> can be kept separate. Which makes my idea of having the first accessor
> select the type of entity pointless.
> > I believe this problem should be solved through a number of simple
> > entity consumer classes that "decorate" the Http(Incoming)Entity
> > interface.
> Ok, so this probably is the fundamental difference between our views at
> the problem. To me, an IncomingEntity is a converter that changes it's
> input, not a decorator that somehow adjusts the view on the underlying
> data. That's why I didn't want to merge the representation of the "raw"
> entity with the converted/interpreted entity into the same class hier-
> archy.
> I imagine some kind of "ProtoEntity", which basically holds the input
> stream and maybe some header fields, from which the "real" entities are
> created. And yes, there is a need to set this "ProtoEntity" on the
> receiving side of HTTP communication. I am finally getting why you want
> to set an incoming entity :-)
> Odi also mentioned the decorator pattern when we discussed the entities
> for the high level design, so my view seems to be a little off. And I
> wouldn't like to introduce an extra interface for the "ProtoEntity"
> either.
> > I can't help thinking we are trying to come up with a solution for a
> > non-existent problem. Design purism aside, the only real issue with the
> > current implementation I know of is that _some_ outgoing entities _may_
> > have _difficulties_ producing an input stream to represent its content.
> > In the extreme case I would rather prefer to see NotSupportedException
> > thrown instead of a whole bunch of otherwise unnecessary and/or ugly
> > interfaces.
> Why not go all the way and move writeTo(OutputStream) also to HttpEntity?
> This would remove the asymmetry that has been created by merging the
> incoming entity with the base interface. That asymmetry is my only
> remaining objection.
> 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