Hi Oleg, Mike's note made me think about this again...
> (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 Do we need a public getInputStream() in the generic interfaces anyway? My idea was that the InputStream is used internally by the (incoming) entity to parse it's content, and that only a stream-type entity would provide "raw" access to it. So I would expect a protected getInputStream() in a base class, rather than a public one in the interface. > (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 My motivation for distinguishing between incoming and outgoing entities was to keep the parsing and generating separate, although that sure is overkill for the many simple entity types. By moving one of the functionalities into the base interface, it becomes mandatory. And thinking of multipart MIME for which there are different parser implementations, I'd rather have the generation than the parsing mandatory. > 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. My idea was to use a factory pattern for instantiating incoming entities: StringEntity se = (StringEntity) response.getIncomingEntity(StringEntity.class) whereas the outgoing entities have a generic writeTo(OutputStream). On the client side, entity enclosing requests would allow setting an outgoing entity, and responses provide incoming entities. On the server, it's the requests that provide the incoming entity and the responses expect an outgoing entity to be set. The opposite operations could either be forbidden, or they could be implemented conditionally for "two-way" entities. So I'd keep the incoming and outgoing entities as distinct attributes in the base class for HttpMessage, rather than casting a single attribute to either side. Again, sorry for not having the time to look into the code. cheers, Roland
