On Thu, Mar 06, 2008 at 01:00:44PM -0500, Jean-Paul Calderone wrote: > > They're equally "event-driven", so I think the feeling you have is only > due to familiarity or personal preference. :)
Maybe. > 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. > > * 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. > > * 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. > > 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. And my idea was needlessly complicated? :) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868
signature.asc
Description: Digital signature
_______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
