[Twisted-web] streaming request (was: status of Twisted Web and Web 2)

Andrew McNabb amcnabb at mcnabbs.org
Thu Mar 6 16:02:53 EST 2008


On Thu, Mar 06, 2008 at 01:00:44PM -0500, Jean-Paul Calderone wrote:
>
> FWIW, IConsumer is a better match here than IProtocol (that's a more or
> less irrelevant detail, though).

I can see why IConsumer would be more appropriate than IProtocol, but
I'm entirely unconvinced by the arguments that IStreamingRequestHandler
would be better than IConsumer.

To start with, I don't understand what an IConsumer has to do with an
IResource.

> That said, here's where I see IStreamingRequestHandler as better than
> re-using an existing interface like IProtocol or IConsumer:
>
>  * IConsumer is a very general interface.  It provides no clues about its
>    interaction with the HTTP protocol implementation.  There's no way to
>    deduce that if an IResource is also an IConsumer that uploads will be
>    streamed to it instead of delivered all at once at the end.  On the
>    other hand, IStreamingRequestHandler can have documentation which
>    describes its purpose and behavior.

I didn't understand this.

>  * IConsumer has existing semantics.  There's no reason an existing
>    IResource implementation might not already be an IConsumer as well,
>    for a completely unrelated reason.  If it suddenly starts to receive
>    streaming upload data, it will almost certainly break.  On the other
>    hand, IStreamingRequestHandler is a new interface, so it cannot be
>    misinterpreted.

If you have to consume two different things, shouldn't you have two
objects?


>  * IConsumer isn't actually sufficiently expressive for this case.  It
>    would be quite useful if the resource had a chance to look at the
>    request headers before streaming begins (okay, I didn't bring this up
>    earlier, so it may have seemed like IConsumer was sufficient).  On the
>    other hand, IStreamingRequestHandler can have a method which takes the
>    request as an argument.

In my opinion, if you need to be looking at request headers before
streaming begins, you're not doing simple streaming, and you should be
hooking in at a lower level.

> It may be the case that the right method for IStreamingRequestHandler to
> have, though, is one which takes the request and returns an IConsumer to
> which the request body will be streamed.

All of the IStreamingRequestHandler stuff sounds more complicated than
necessary.  I think I'm convinced that IConsumer is a good way to go.
It uses existing mechanisms to do something simple.
IStreamingRequestHandler, however, would create new mechanisms to do
something complicated.

-- 
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20080306/d105c559/attachment.pgp


More information about the Twisted-web mailing list