[Web-SIG] Request and Response objects

[Randy Pearson]

The case seems to be whether to have two closely-coordinated
request/response objects versus a single object. I can see a few points in
favor of the former:

1. Independence for extensibility. By having separate classes for each
object, they are free to grow independently. So, if Jane develops an
intersesting extension to the Request class (by way of subclassing), and Bob
does the same for the Response class, it becomes much easier to combine
these in a best-of-breed approach. If all one class, this would be difficult
or impossible.

2. Multiplicity. If a single object is used, there is an implicit assumption
of a 1:1 relation between requests and responses. But is that always the
case? Consider two cases. Case 1: Your "response" to a request includes both
the standard response _and_ a generated email of content-type text/html.
Case 2: You have a mixed-mode site that includes both static and dynamic
content, and in some instances you update some of the static (published)
content in response to an incoming request. In both of these cases, you are
producing more than one "response", and if your response class encapsulates
the ability to produce both, you might easily want to operate on multiple
response objects in parallel.

3. Timing. If processing a request may cause a time-out, you may prefer to
queue the request and provide the usual auto-refresh type of HTML response,
polling for completion status. In this case, you have new needs: the ability
to queue a request and the ability to store and resurrect a response. It's
hard to see a single combined object dealing with all of this.

Perhaps some form of a mediator or facade could be created to provide an
interface between these objects, but in any event, they don't strike me as
deriving from a single class.

-- Randy