Go for it. Simplicity sounds like the way to go.
Mike
On 5/1/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
