A "HTTP entity" is the body of a HTTP message.
The "request entity" is the "HTTP entity" in a request
whereas the "response entity" is the "HTTP entity" in a response. On the protocol level (as opposed to the API level) the two are not any different. The respective headers contain some meta information about what is going to be in the enclosed entity (like transfer encoding, content type, size, etc.). But the entity looks exactly the same in a request and in a response. So the semantics suggest we have only one interface to that thing called entity. How such an entity is produced or consumed (write / parse) is not in the responsibility of the entity object. It rather is the responsibility of entity producers and consumers (reader / writer, source / drain).
The only thing we need to do with an entity is read it. At request time we read it and stream it to the server (use case A). At response time the client reads from it to get the content (use case B). How the content of the entity is produced should NOT be part of the interface specification. It may be stored as a file on disk, may be the input stream from the server, may be a multipart entity consisting of serveral files on disk and memory, anything else.
The two use cases are *different* implementations of that one interface.
So why not just make a host of classes that implement this simple interface and provide an entity in different ways. Not specifying how the entity is produced makes this whole architecture more flexible and less complex!
my $0.02
Odi
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
