Hi Oleg, sounds reasonable. Go ahead. Do you want to add a method to HttpEntity for checking whether a non-repeatable entity has already been consumed?
I'm sorry that I currently don't have the time to dig into the new code. cheers, Roland Oleg Kalnichevski <[EMAIL PROTECTED]> wrote on 26.04.2005 11:05:36: > Folks, > > After having spent some time working on the http-common API I would like > to propose some changes to HttpEntity, HttpIncomingEntity & > HttpOutgoingEntity interfaces. > > 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. > > (1) Fundamentally the distinction between HttpIncomingEntity and > HttpOutgoingEntity behaviors is not necessary > > (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 > > (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 > > This approach may create some problems for non-repeatable entities such > as InputStreamEntity but they can be resolved by maintaining the object > state and refusing to stream out the content if it has already been > consumed through getInputStream method. I feel this is a small price to > pay for a much less irritating API > > What you think? > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
