[Web-SIG] Proposal: Avoiding Serialization When Stacking Middleware
Phillip J. Eby
pje at telecommunity.com
Tue Mar 13 21:12:43 CET 2007
At 02:47 PM 3/13/2007 -0500, Ian Bicking wrote:
>The open issues section has three issue. One is a matter of defining some
>naming convention, and as long as people *try* to match up their
>conventions it will work. The second has a proposed solution. The last
>is merely aesthetic.
>
>These are the "real issues" you are referring to?
No - I'm saying that the real issues are all (and always) specific to the
particular data type being exchanged.
>That's not much easier, really. It would still be documented, still needs
>to be implemented and defined properly. The biggest difference is that it
>needs to be done again for each type of object.
It has to be anyway.
>I didn't understand what you were proposing, I think. I still don't
>really know what get_file_storage means.
It would return a cgi.file_storage encoding the request body.
>It's a nice idea, but as far as I know no one has actually used
>wsgi.file_wrapper.
I believe that the Jython WSGI implementation provides one, or something
analagous that wraps certain types of Java stream objects.
>Except insofar as "type" is variable in my specification, I don't think it
>is substantially different.
That is indeed the substance of the difference - yours is a
meta-specification, rather than a specification. As a result, it's more
complicated to grasp than a pattern... and significantly more difficult to
get *right*. And without examples, it's basically impossible to get right.
>If no one cares about this, then I guess I can just put it under the
>httpencode namespace where it was before, but I don't see any reason to
>make it less general.
It'll be worth making it general when there are more examples of the
pattern to generalize from. As you pointed out yourself, there are very
few at the moment.
More information about the Web-SIG
mailing list