[Web-SIG] Request/Response features
ianb at colorstudy.com
Thu Oct 23 11:21:17 EDT 2003
On Thursday, October 23, 2003, at 05:05 AM, David Fraser wrote:
>> The interface I wrote is at:
> 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:
> would be good to have some consistency between these names
They are mostly based off their CGI environment equivalent.
> I don't think the ordering is generally important to people, so why
> not ignore it, because if people want to preserve it, they can always
> write some code to do that, but it's hardly needed as default
I agree, it should go.
> 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.
> 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.
> 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.
> 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.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG