Folks,
How do you feel about moving writeTo(OutputStream) method from
HttpStreamableEntity (former HttpOutgoingEntity) to HttpEntity interface
and removing HttpStreamableEntity interface at all?
Oleg
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
