Jim Fulton wrote:
It all gives indication. Yes, if only one person says this sucks,
then their opinion may not be worth changing the implementation for.
However, if 50% of users said this sucks, even if they couldn't
explain why, that'd be something worth worrying about.
Sure, but how
Jim Fulton wrote:
I do a lot of unix deployment, and the thought of a buildout that
sprays files all over the system, even if they are in standard unix-y
location scares me a lot...
That's because you are a developer.
OK, I see what you mean now, although I think it's clear that
Phillip J. Eby wrote:
basically, where each object type results in a new key in the
environment and a new ad hoc specification to be made (e.g.,
wsgi.file_wrapper takes a block size, which is specific only to that
case).
Right. I'm specifically saying that a collection of individual
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
Phillip J. Eby wrote:
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.
I still don't understand. Are you talking about cgi.FieldStorage? Are
you talking about an
Phillip J. Eby wrote:
At 03:14 PM 3/13/2007 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
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.
I still don't understand.
At 04:15 PM 3/13/2007 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 03:14 PM 3/13/2007 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
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
