[Web-SIG] Request/Response features

[David Fraser]

Ian Bicking wrote:

> On Thursday, October 23, 2003, at 05:05 AM, David Fraser wrote:
>
>>> The interface I wrote is at:
>>>
>>>   http://colorstudy.com/~ianb/IHTTP_01.py
>>
>> Had a look at this, it's nice for a start. However I agree with you 
>> that the transaction interface is confusing... for example, what does 
>> "setTransaction" mean/do?
>
> Some of the methods were for setting up the request, or modifying the 
> request so it can be forwarded internally.  It might be fine to leave 
> the request/response setup undefined -- it would be defined by the 
> context, e.g., cgi would set it up one way, mod_python another, etc.  
> For forwarding I think it might be better to simply create new object 
> that would be reinjected into the framework.
>
>> Some other comments:
>> pathInfo/requestURI
>>  would be good to have some consistency between these names
>
> They are mostly based off their CGI environment equivalent.

OK, now I understand, but is this a good way to name things for the future?

>> getFieldDict
>>  It would be great if the user could set the behaviour they want for 
>> multiple keys.
>>  I know I *always* want to discard any extra values. Including an 
>> option to do this rather than return a list would prevent lots of 
>> people doing post-processing
>
> That seems to difficult to define.  I don't think there should be 
> customizations, because that makes it too difficult to work in a 
> heterogeneous environment.  If you turn that setting on and some 
> application you are using needs it off, then you get a configuration 
> mess.  Wrappers could provide more friendly interfaces.

If you defined a setField method as you said above, then people could 
override it to throw away duplicate values. Maybe this is the way to go

>> General comment here: there are quite a few different methods to 
>> handle getting/setting get/post fields. Perhaps this would be made 
>> simpler by using a standard dictionary interface. That would also 
>> clear up confusion about what parameters to pass to setFieldDict etc. 
>> Another question is whether people really need get and post arguments 
>> to be processed differently.
>
> People do need to access them separately, as that's a common feature 
> request.  Usually they'd be accessing some combined version of those, 
> but the option should be there.

Fine. So we need a clever way of providing them in either form. I think 
using dictionaries for this is essential - even if it means defining a 
single dictionary that remembers which fields are get and which are 
post, and provides different wrappers to see the different elements.

>> Also, is it neccessary for all attributes to be accessed by methods? 
>> Particularly (no pun intented) things like "method", "time" would 
>> seem to make more sense as attributes. If anyone really needs to run 
>> some code to access them,
>
> I wrote the interface with wrappers in mind, and I thought purely 
> using methods would be easier and more explicit.

It is more explicit, but I don't think it's easier. It may require a few 
extra lines of code for some servers to require attributes, but it makes 
the user side much easier. The server side gets written once, many users 
use it, so it makes sense to make things as easy as possible for the user.
For example, the DB-API has an attribute called rowcount. In order to 
implement that, I had to create a getrowcount() method, then put in a 
__getattr__ method that called getrowcount() to read the rowcount 
attribute. A few lines of code. But it makes all the client-side code 
much more logical and easier to read.
Obviously this is a tradeoff and some things should be methods, some 
should be attributes.

>> The input method seems strange. Perhaps this should be called read? 
>> In general, there needs to be a clear separation between low-level 
>> accessing of the request stream, and higher-level accessing of 
>> processed get/post fields. Perhaps a way to do this would be to 
>> analyse how the most popular existing servers do things, then define 
>> a set of low-level methods which would cover their functionality. If 
>> this was done well, the higher-level methods could be written so that 
>> they always fall back to use the underlying low-level methods if they 
>> aren't overridden, so at least people only have to implement basic 
>> functionality to match the API.
>
> I guess there's two ways you could go with that -- if a method is 
> derivative of other methods, then just leave it out and let a wrapper 
> implement it.  But that doesn't work particularly well if we want to 
> use the request/response as part of the standard library (without any 
> wrapper in the library).  So an abstract base class might be a good 
> idea, with subclasses implementing the actual construction and some of 
> the basic methods.

Right, abstract base class + simple implementation is the way to go.

David