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. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
