From: Patrick May <patrick@...>
Date: 2004-08-23T18:16:03+09:00
Subject: Re: Separation of Web Request and Response (was: Re: Idea: Webshare)

Hello,

On Saturday, August 21, 2004, at 06:25  PM, Robert Klemme wrote:
> There are in fact good reasons in favor of the request / response 
> split.
> First of all request and response are in fact two different things, so 
> from
> that point of view it's not a bad idea to separate them.  The 
> interface of a
> combined request response instance is likely to get too bloated.

I don't really think that request / response are all that different.  
They share the connection to the client.

An object with many methods is one kind of bloat.  Managing two objects 
that share the same resource and lifecycle causes another kind of 
bloat.  The latter bloat is the kind that leads to bugs in my code.

For example, the library should delete the Tempfiles containing file 
uploads (request state) when the final output is written and the 
connection is closed (response state).  A single object with a single 
lifecycle makes this sort of thing easier to support.

> There are
> use cases where you only need the response (say, a page that displays 
> the
> current time) and there might be others where you don't need the 
> response
> (can't think of any at the moment though, some kind of upload maybe 
> :-)).

I don't think the object will mind if you don't call all of its 
methods.  Just ask aString :-)

> Another reason why I liked the separation (in Java) is that you can 
> easily
> wrap only one of them (common with filters in Java, but similar things 
> can
> be done with Ruby, too); examples are filtering of whitespace from the
> response and adding default values for request parameters.  If request 
> and
> response are encapsulated in a single instance this becomes much more
> difficult to do - and the fun goes away. :-)

You should be able to do this in Narf:

    Web["param"] ||= "a value"

Note that the single object I recommend that you use is the Web module. 
  That way, you don't have to pass anything around!  The output filter 
isn't something I've thought about, but I think it is a good idea.

I don't want to be entirely negative. These are use cases I want to 
support.  I tried designing a Request / Response style interface.  I 
found that the separation made things more difficult for me.  I 
apologize for the earlier <rant />.

Cheers,

Patrick