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 Fri, 29 Apr 2005 09:50:52 GMT
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-
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"

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


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