PEP 444 != WSGI 2.0

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 != WSGI 2.0

Alice Bevan–McGregor
On 2011-01-02 11:57:19 -0800, P.J. Eby said:
> FWIW, my lack of interest has been due to two factors.  First,
> theoriginal version of PEP 444 before you worked on it was questionable
> in my book, due to the addition of new optional features (e.g. async),
> and second, when I saw your "filters" proposal, it struck meas more of
> the same, and put me off from investigating further.  (Thewhole idea of
> having a WSGI 2 (IMO at least), was to get rid of cruft and fix bugs,
> not to add new features.)

Interestingly, I see PEP 444 / WSGI 2 as the oppostie; 3333 fixes the
major outstanding bugs that block Python 3 compatibility without
improving anything else, 444 is an opportunity to shape the future by
making previously optional things required (like HTTP/1.1 support) and
adding features that individual framework authors have all implemented
in incompatible ways (async).

> Reading the draft now (I had not done so previously), I would
> suggestmaking your filters proposal available as a standalone module
> (or anaddition to a future version of wsgiref.util), for anybody who
> wantsthat feature, e.g. via:

The filtering API is marked as optional, with an example of using it as
middleware.

> (Writing this implementation highlights one problem with the notionof
> filters, though, and that's that egress filters can't trap anerror in
> the application.)

Egress filters only run on successful (non-exceptional) resopnses; if
you need to capture exceptions to return non-exceptional responses
(e.g. debugging), you use middleware.  This is not a bug, it's a design
feature.  :)

> As far as the rest of the draft is concerned, in order to give
> *thorough* technical feedback, I'd need to first make sure that all of
> the important rules from 3333 are still present, which is hard todo
> without basically printing out both PEPs and doing a line-by-line
> analysis.

I'll do so.

> I notice that file_wrapper is missing, for example, but am not clear on
> the rationale for its removal.  Is it your intention that
> serverswishing to support file iteration should check for a fileno()
> directly?

No, file_wrapper was missing because it's simply one thing I haven't
gotten around to declaring in a point-by-point RFC manner yet.  :/

> There are a number of minor errors in the draft, such as saying that
> __iter__ must return a bytes instance (it should return an iterator
> yielding bytes instances) and __iter__ itself has broken markup.

I've corrected my local copy and will push after reading some
additional messages.

> * I remain a strong -1 on the .script_name and .path_info variables
> (one of which is named incorrectly in the draft), for reasons outlined
> here previously.  (Specifically, that environ redundancy is a train
> wreck for middleware, which must be written to support bothways of
> providing the same variable, or to delete the extended version when
> modifying the environment.)

Agreed.

> * -1 on the key-specific encoding schemes for the various CGI
> variables' values -- for continuity of coding (not to mention
> simplicity) PEP 3333's approach to environ encodings should beused.  
> (That is, the environ consists of bytes-in-unicode-form, rather than
> true unicode strings.)

Does ISO-8859-1 not accomodate this for all but a small number of the
environment variables in PEP 444?  (Specifically, variables refering to
parts of the URL/URI.)  And for those variables decoded differently,
there is an environment variable containing the encoding used.

> * +1 to requiring Python 2.6 -- standardizing on b'' notation makesgood
> sense and improves forward-portability to Python 3.

In /theory/ you could write a PEP 444-compliant server specifically for
versions of Python < 2.6, this is not likely to be done, however.

> * Where is the PARAMETERS variable defined in the CGI spec?  
> Whatservers actually support it?

It's defined in the HTTP spec by way of
http://www.ietf.org/rfc/rfc2396.txt URI Syntax.  These values are
there, they should be available.  (Specifically semi-colon separated
parameters and hash-separated fragment.)

> * The language about empty vs. missing environment variables appears to
> have disappeared; without it, the spec is ambiguous.

I will re-examine the currently published PEP 444.

> Those are the issues I have identified on a first reading, without
> doing a full analysis.  However, in lieu of such an analysis, I would
> take Graham's word on whether or not your spec addresses the HTTP
> compliance/implementation issues found in previous WSGI specs.

In point of fact, I have been, but I need more in comment than "that
won't work".

> If I may offer a recommendation from previous experience steering this
> PEP, I would say that just because other people know (say) HTTP better
> than you, doesn't mean that you can't still make a better specthan they
> can.  You don't have to make *your* proposal into *Graham's* spec, or
> even the spec that Graham would have wanted youto make.  But you *do*
> need to take Graham's *goals* into consideration.

Indeed.  I do try to understand the issues covered in a broader scope
before writing; for example, I do consider the ability for new
developers to get up and running without worrying about the example
applications they are trying to use work in their version of Python;
thus /allowing/ native strings to be used as response values on Python
3.

Byte strings are still perferred, and may be more performant, but
getting started becomes much easier.  This is just one of the points I
happened to agree on.  ;)

> During the original drafting of PEP 333, Ian proposed quite a lot of
> features that I shot down...  but I modified what I was doing so that
> Ian could still achieve his *goals* within the spec, without
> compromising my core vision for the spec (which was that it should be
> as close to trivial for server implementers as possible, and not expose
> any application API that might be perceived by framework developers as
> competition).

There's a difference between /competition/ and /eliminating pointless,
incompatible reimplementation/.  A -simple for the application
developer- async specification will ensure portable, more easily
tested, consistent solutions.

> So, I urge you to pay attention when Graham says something about
> whatthe spec is lacking or how it's broken.

I certainly will; I just need to see concrete points against the
technical merits of the rewritten PEP, not pointless arguing about the
name of a draft document.  ;)

Thank you for your input!

        - Alice.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 != WSGI 2.0

Masklinn
In reply to this post by Alice Bevan–McGregor
On 2011-01-02, at 23:16 , Alice Bevan–McGregor wrote:
>> (Just trying to keep this thread from degenerating into a shouting match.)
> I missed how his statements could be construed as offensive.  :/
I missed it as well (though my report might have been brusque), and definitely didn't intent it to be offensive.

>  I interpreted the multiple "you can't" references to be careless shorthand
Yes, it was intended as a short report from the previous discussion's gist/result (or more precisely my potentially incorrect recollection of it), and aimed at suggesting that you check out that previous thread, not as a statement of fact (let alone personal criticism or attacks).

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 != WSGI 2.0

PJ Eby
In reply to this post by Graham Dumpleton-2
At 12:38 PM 1/2/2011 -0800, Alice Bevan­McGregor wrote:
>On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>>>I'd suggest we just embrace it, adding minor tweaks as necessary,
>>>until we reach some sort of technical impasse it doesn't address.
>
>Async is one area that 3333 does not cover, and that by not having a
>standard which incorporates async means competing, incompatible
>solutions have been created.

Actually, it's the other way 'round.  I wrote off async for PEP 333
because the competing, incompatible solutions that already existed
lacked sufficient ground to build a spec on.

In effect, any direction I took would effectively have either blessed
one async paradigm as the correct one, or else been a mess that
nobody would've used anyway.

And this condition largely still exists today: about the only common
ground between at least *some* async Python frameworks today is the
use of greenlets...  but if you have greenlets, then you don't need a
fancy async API in the first place, because you can just "block"
during I/O from the POV of the app.

The existence of a futures API in the stdlib doesn't alter this much,
either, because the async frameworks by and large already had their
own API paradigms for doing such things (e.g. Twisted deferreds and
thread/process pools, or generator/greenlet-based APIs in other frameworks).

The real bottleneck isn't even that, so much as that if you're going
to write an async WSGI application, WSGI itself can't define enough
of an async API to let you do anything useful.  For example, you may
still need database access that's compatible with the async
environment you're using...  so you'd only be able to write portable
async applications if they didn't do ANY I/O outside of HTTP itself!

That being the case, I don't see how a meaningfully cross-platform
async WSGI can ever really exist, and be attractive both to
application developers (who want to run on many platforms) and
framework developers (who want many developers to choose their platform).


>On 2011-01-02 12:00:39 -0800, Guido van Rossum said:
>>Actually that does sound like an opinion on the technical merits. I
>>can't tell though, because I'm not familiar enough with PEP 444 to
>>know what the critical differences are compared to PEP 3333. Could
>>someone summarize?
>
>Async, distinction between byte strings (type returned by
>socket.read), native strings, and unicode strings,

What distinction do you mean?  I see a difference in *how* you're
distinguishing byte, native, and unicode strings, but not *that*
they're distinguished from one another.  (i.e., PEP 3333
distinguishes them too.)


>thorough unicode decoding (moving some of the work from middleware
>to the server),

What do you mean by "thorough decoding" and "moving from middleware
to server"?  Are these references to the redundant environ variables,
to the use of decoded headers (rather than bytes-in-unicode ones), or
something else?


>The async part is an idea in my head that I really do need to write
>down, clarified with help from agronholm on IRC.  The futures PEP is
>available as a pypi installable module, is core in 3.2, and seems to
>provide a simple enough abstract (duck-typed) interface that it
>should be usable as a basis for async in PEP 444.

I suggest reviewing the Web-SIG history of previous async
discussions; there's a lot more to having a meaningful API spec than
having a plausible approach.  It's not that there haven't been past
proposals, they just couldn't get as far as making it possible to
write a non-trivial async application that would actually be portable
among Python-supporting asynchronous web servers.

(Now, if you're proposing that web servers run otherwise-synchronous
applications using futures, that's a different story, and I'd be
curious to see what you've come up with.  But that's not the same
thing as an actually-asynchronous WSGI.)  

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Fwd: PEP 444 != WSGI 2.0

Benoit Chesneau-3
In reply to this post by Alice Bevan–McGregor
---------- Forwarded message ----------
From: Benoit Chesneau <[hidden email]>
Date: Sun, Jan 2, 2011 at 10:51 PM
Subject: Re: [Web-SIG] PEP 444 != WSGI 2.0
To: Alice Bevan–McGregor <[hidden email]>


On Sun, Jan 2, 2011 at 9:38 PM, Alice Bevan–McGregor
<[hidden email]> wrote:
> On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>>>
>>> I'd suggest we just embrace it, adding minor tweaks as necessary, until
>>> we reach some sort of technical impasse it doesn't address.
>
> Async is one area that 3333 does not cover, and that by not having a
> standard which incorporates async means competing, incompatible solutions
> have been created.
>

I don't see why async need a specific handling in the spec. What
differences do you need ? Today users are perfectly abble to manage
async using gevent, eventlet, ... behind WSGI 1.0 .

- benoît
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 != WSGI 2.0

PJ Eby
In reply to this post by Alice Bevan–McGregor
At 02:21 PM 1/2/2011 -0800, Alice Bevan­McGregor wrote:
>On 2011-01-02 11:57:19 -0800, P.J. Eby said:
>>* -1 on the key-specific encoding schemes for the various CGI
>>variables' values -- for continuity of coding (not to mention
>>simplicity) PEP 3333's approach to environ encodings should beused.
>>(That is, the environ consists of bytes-in-unicode-form, rather
>>than true unicode strings.)
>
>Does ISO-8859-1 not accomodate this for all but a small number of
>the environment variables in PEP 444?

PEP 3333 requires that environment variables contain the bytes of the
HTTP headers, decoded using ISO-8859-1.  The unicode strings, in
other words are restricted to code points in the 0-255 range, and are
really just a representation of bytes, rather than being a unicode
decoding of the contents of the bytes.

What I saw in your draft of PEP 444 (which I admittedly may be
confused about) is language that simply loosely refers to unicode
environment variables, which could easily be misconstrued as meaning
that the values could actually contain other code points.

To be precise, in PEP 333, the "true" unicode value of an environment
variable is:

     environ[key].encode('iso-8859-1').decode(appropriate_encoding_for_key)

Whereas, my reading of your current draft implies that this has to
already be done by the server.

As I understand it, the problem with this is that the server
developer can't always provide such a decoding correctly, and would
require that the server guess, in the absence of any information that
it could use to do the guessing.  An application developer is in a
better position to deal with this ambiguity than the server
developer, and adding configuration to the server just makes
deployment more complicated, and breaks application composability if
two sub-applications within a larger application need different decodings.

That's the rationale for the PEP 3333 approach -- it essentially
acknowledges that HTTP is bytes, and we're only using strings for the
API conveniences they afford.



>>* Where is the PARAMETERS variable defined in the CGI spec?
>>Whatservers actually support it?
>
>It's defined in the HTTP spec by way of
>http://www.ietf.org/rfc/rfc2396.txt URI Syntax.  These values are
>there, they should be available.  (Specifically semi-colon separated
>parameters and hash-separated fragment.)

I mean, what web servers currently provide PARAMETERS as a CGI
variable?  If it's not a CGI variable, it doesn't go in all caps.

What's more, the spec you reference points out that parameters can be
placed in *each* path-segment, which means that they would:

1) already be in PATH_INFO, and
2) have multiple values

So, -1 on the notion of PARAMETERS, since AFAICT it is redundant, not
CGI, and would only hold one parameter segment.


>>* The language about empty vs. missing environment variables
>>appears to have disappeared; without it, the spec is ambiguous.
>
>I will re-examine the currently published PEP 444.

I don't know if it's in there or not; I've read your spec more
thoroughly than that one.  I'm referring to the language from PEP 333
and its successor, with which I'm much more intimately familiar.


>Indeed.  I do try to understand the issues covered in a broader
>scope before writing; for example, I do consider the ability for new
>developers to get up and running without worrying about the example
>applications they are trying to use work in their version of Python;
>thus /allowing/ native strings to be used as response values on Python 3.

I don't understand.  If all the examples in your PEP use b'' strings
(per the 2.6+ requirement), where is the problem?

They can't use WSGI 1(.0.1) code examples at all (as your draft isn't
backward-compatible), so I don't see any connection there, either.


>Byte strings are still perferred, and may be more performant,

Performance was not the primary considerations; they were:

* One Obvious Way
* Refuse The Temptation To Guess
* Errors Should Not Pass Silently

The first two would've been fine with unicode; the third was the
effective tie-breaker.  (Since if you use Unicode, at some point you
will send garbled data and end up with an error message far away from
the point where the error occurred.)


>I certainly will; I just need to see concrete points against the
>technical merits of the rewritten PEP

Well, I've certainly given you some, but it's hard to comment other
than abstractly on an async spec you haven't proposed yet.  ;-)

Nonetheless, it's really important to understand that the PEP process
(especially for Informational-track standards) is not so much about
technical merits in an absolute sense, as it is about *community consensus*.

And that means it's actually a political and marketing process at
least as much as it is a technical one.  If you miss that, you may
well end up with a technically-perfect spec (in the sense that nobody
gives you any additional "concrete points against the technical
merits"), that nobody cares to actually *implement*.

And from a marketing perspective, the people who must "buy" a WSGI 2
spec are the *server implementers*.

Sure, if you have a well-defined mapping from WSGI 1.0.x to your
spec, then you could write a wrapper that provides your spec in any
WSGI 1.0.x server -- and you can then promote that API for people to
use.  However, you would then be in the web development API business,
competing against dozens of existing web frameworks for
mindshare.  Why use it over any other such API?

So, in order to make the spec a meaningful point of coordination,
both sides of the spec need some reasonable expectation that the
people on the other side are really going to use/implement it.

But the *costs* of implementing are asymmetric: writing code against
(any given spec for) WSGI 2 is a lower commitment than actually
implementing the corresponding WSGI 2 server.  Which means it's
harder to convince a server implementer to just do something
different because it's nicer for the end-user.  (Nice for the
end-user, after all, is the application framework's job, from the
server developer's POV!)

This isn't to say you shouldn't make things nicer for users; but your
spec will likely be successful to the degree it *also* makes things
nicer for server developers...  like Graham and Robert, among others.

So, the good news is, your real target audience is already here,
listening, and occasionally commenting on these matters.  The bad
news is, making them happy has less to do with technical merit per
se, and much more to do with how much work they see your spec making
for them.  Welcome to the PEP process.  ;-)

Hm.  That didn't sound quite right: it's not that server developers
don't care about technical merit.  It's that the technical merits
they're most interested in are going to fall on the side of things
like needing to handle ambiguities at the interface between HTTP and
the WSGI spec.  So a new spec that doesn't address *known* issues
with HTTP-WSGI relations may be perceived by some as pointless noise
that isn't helping anything...  and from *their* perspective, they're right.

While it'd be nice if the burden of proof were on them to tell you
where your spec is wrong, this simply isn't practical.  Reviewing
every spec that comes along is time-consuming and *hard*.  (To be
quite honest, I was previously hoping that somebody else besides me
would do the initial reviewing of your spec -- and I don't plan to
review every draft or do a super-detailed assessment unless it
clearly becomes necessary!)

And, whether it's true or fair, a quick glance at your draft can
easily give the impression to a long-time Web-SIGger that you haven't
studied the pitfalls that Graham has so extensively documented in the
past, or that if you did, you didn't give much thought to resolving them.

Again, I don't know if you've done so, but if you have, it's not
immediately apparent to me from your current draft. And it really is
up to you to promote and defend your PEP, not up to others to shoot it down.

All that being said, I've pitched in today to give some feedback and
support because I *want you to succeed*.  The disadvantage to being
an old hand at this is that it's easy to be discouraged by one's own
extensive knowledge of the problems, and it's great to have somebody
with some fresh enthusiasm stepping up to the plate.  (Lord knows I
don't want to have to write the damn thing myself!)

But that won't change the part where to get *other* people on board,
you're going to have to convince them that you have a credible
solution to the problems *they* care about, not just the ones you
care about.  Writing a rationale that will convince Graham and the
others that you've got a solution to the problems they've already
posted about so many times is really Job 1 here if you want to get
their buy-in.

If you get stuck on some element of what they're asking
for/complaining about, feel free to post a question here, and I will
certainly chime in and try to help out.  However, if you keep
thinking about the part where the overall process is inherently
unfair to you -- which I totally agree it *is* -- it's not going to
do anything but stress you out.

And I don't want *that*, because I don't want you to get burned out
before you do the job of writing the next spec for me.  ;-)

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 != WSGI 2.0

Tres Seaver
In reply to this post by Guido van Rossum
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/02/2011 04:31 PM, Guido van Rossum wrote:

> On Sun, Jan 2, 2011 at 12:55 PM, Masklinn <[hidden email]> wrote:
>
>> On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote:
>>> On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>>>>> I'd suggest we just embrace it, adding minor tweaks as necessary, until
>> we reach some sort of technical impasse it doesn't address.
>>> Async is one area that 3333 does not cover, and that by not having a
>> standard which incorporates async means competing, incompatible solutions
>> have been created.
>>>
>> If I remember the previous Web3 discussion correctly, the result was
>> basically that async has no business being shoehorned in WSGI, that WSGI's
>> model is fundamentally unfit for async and you can't correctly support sync
>> and async with the same spec, and therefore an asynchronous equivalent to
>> WSGI should be developed separately, in order to correctly match the needs
>> of asynchronous servers and interfaces, without the cruft and inadequacies
>> of being forked from a synchronous gateway model.
>>
>
> Masklinn, those are pretty strong words (bordering on offensive). I'm sure
> Alice has a different opinion. Alice, hopefully you can write down your
> ideas for all to see? Perhaps you have an implementation too? Maybe seeing a
> concrete proposal will help us all see how big or small of a shoehorn will
> be needed.

I didn't read that as offensive, but as an accurate description of the
de-facto consensus of the SIG:  there is a *very* small minority who
want next-WSGI to address async issues (AFAIK, Alice and Manlio are the
only active proponents).


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          [hidden email]
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0hPasACgkQ+gerLs4ltQ6x5wCfdoX2n+Dpt5wQkY6i8Q8r7hlD
J60An1ZszrZmyfB3S+IGmloHXM4JYTBg
=WCCE
-----END PGP SIGNATURE-----

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: PEP 444 != WSGI 2.0

Guido van Rossum
On Sun, Jan 2, 2011 at 7:08 PM, Tres Seaver <[hidden email]> wrote:

> On 01/02/2011 04:31 PM, Guido van Rossum wrote:
>> On Sun, Jan 2, 2011 at 12:55 PM, Masklinn <[hidden email]> wrote:
>>
>>> On 2011-01-02, at 21:38 , Alice Bevan–McGregor wrote:
>>>> On 2011-01-02 11:14:00 -0800, Chris McDonough said:
>>>>>> I'd suggest we just embrace it, adding minor tweaks as necessary, until
>>> we reach some sort of technical impasse it doesn't address.
>>>> Async is one area that 3333 does not cover, and that by not having a
>>> standard which incorporates async means competing, incompatible solutions
>>> have been created.
>>>>
>>> If I remember the previous Web3 discussion correctly, the result was
>>> basically that async has no business being shoehorned in WSGI, that WSGI's
>>> model is fundamentally unfit for async and you can't correctly support sync
>>> and async with the same spec, and therefore an asynchronous equivalent to
>>> WSGI should be developed separately, in order to correctly match the needs
>>> of asynchronous servers and interfaces, without the cruft and inadequacies
>>> of being forked from a synchronous gateway model.

>> Masklinn, those are pretty strong words (bordering on offensive). I'm sure
>> Alice has a different opinion. Alice, hopefully you can write down your
>> ideas for all to see? Perhaps you have an implementation too? Maybe seeing a
>> concrete proposal will help us all see how big or small of a shoehorn will
>> be needed.
>
> I didn't read that as offensive, but as an accurate description of the
> de-facto consensus of the SIG:  there is a *very* small minority who
> want next-WSGI to address async issues (AFAIK, Alice and Manlio are the
> only active proponents).

That's not what Masklinn appeared to be saying though. He implied that
it was a bad idea, not that nobody was interested. Also he used an
excessive number of negative terms ("has no business", "shoehorn",
"fundamentally unfit", "cruft"). If he had said it the way you said it
I would have remained silent. But I accept that I overreacted, and no
offense was taken by Alice, so this is all academic. The best way
forward for async is likely a separate PEP.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

CGI in PEP 444

Antoine Pitrou
In reply to this post by Alice Bevan–McGregor
Alice Bevan–McGregor <alice@...> writes:
>
> [1] http://bit.ly/e7rtI6

So, while we are at it, could we get rid of the "CGI server example" in this new
SWGI spec?
This is 2011, and we should promote modern idioms, not encourage people to do
1995 Web programming. 10 years ago, CGI was already frown upon.
(and even the idea that WSGI should provide some kind of CGI compatibility
sounds a bit ridiculous to me)

Regards

Antoine.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

hidura
Agree, i develop an excelent wsgi server in Py3k, without use the cgi
library to extract the data, so is better if in the manual kills the
part that indicate use the cgi lib to extract the data.

2011/1/4, Antoine Pitrou <[hidden email]>:

> Alice Bevan–McGregor <alice@...> writes:
>>
>> [1] http://bit.ly/e7rtI6
>
> So, while we are at it, could we get rid of the "CGI server example" in this
> new
> SWGI spec?
> This is 2011, and we should promote modern idioms, not encourage people to
> do
> 1995 Web programming. 10 years ago, CGI was already frown upon.
> (and even the idea that WSGI should provide some kind of CGI compatibility
> sounds a bit ridiculous to me)
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/hidura%40gmail.com
>

--
Enviado desde mi dispositivo móvil

Diego I. Hidalgo D.
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

PJ Eby
In reply to this post by Antoine Pitrou
At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
>Alice Bevan­McGregor <alice@...> writes: > > [1]
>http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
>the "CGI server example" in this new SWGI spec? This is 2011, and we
>should promote modern idioms, not encourage people to do 1995 Web
>programming. 10 years ago, CGI was already frown upon. (and even the
>idea that WSGI should provide some kind of CGI compatibility sounds
>a bit ridiculous to me) Regards Antoine.

I still use CGI for the odd one-off, testing, prototyping, etc., and
it's by far the easiest thing to deploy on a lot of web hosts.  Hell,
even Google App Engine *emulates* CGI in its default deployment
configuration, IIRC.  So it's not exactly obsolete.

Also, the main purpose of the example is to show what a web server
developer needs to do to hook up their own piping to provide WSGI
services...  and most web server developers have something like CGI
code already lying around, or at least know what CGI looks like.




>  _______________________________________________ Web-SIG mailing
> list [hidden email] Web SIG: http://www.python.org/sigs/web-sig 
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/pje%40telecommunity.com

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

rdsteph@mac.com
CGI is by far the quickest and easiest way to write and deploy very simple web site scripts. As you move to improve Python for important industrial strength web programming, why not also continue to support quick and dirty web interactivity scripts?

Ron Stephens

Sent from my iPhone

On Jan 4, 2011, at 7:53 AM, "P.J. Eby" <[hidden email]> wrote:

> At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
>> Alice Bevan McGregor <alice@...> writes: > > [1] http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of the "CGI server example" in this new SWGI spec? This is 2011, and we should promote modern idioms, not encourage people to do 1995 Web programming. 10 years ago, CGI was already frown upon. (and even the idea that WSGI should provide some kind of CGI compatibility sounds a bit ridiculous to me) Regards Antoine.
>
> I still use CGI for the odd one-off, testing, prototyping, etc., and it's by far the easiest thing to deploy on a lot of web hosts.  Hell, even Google App Engine *emulates* CGI in its default deployment configuration, IIRC.  So it's not exactly obsolete.
>
> Also, the main purpose of the example is to show what a web server developer needs to do to hook up their own piping to provide WSGI services...  and most web server developers have something like CGI code already lying around, or at least know what CGI looks like.
>
>
>
>
>> _______________________________________________ Web-SIG mailing list [hidden email] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/pje%40telecommunity.com
>
> _______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/rdsteph%40mac.com
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

Antoine Pitrou
In reply to this post by PJ Eby
P.J. Eby <pje@...> writes:

>
> At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
> >Alice Bevan­McGregor <alice@...> writes: > > [1]
> >http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
> >the "CGI server example" in this new SWGI spec? This is 2011, and we
> >should promote modern idioms, not encourage people to do 1995 Web
> >programming. 10 years ago, CGI was already frown upon. (and even the
> >idea that WSGI should provide some kind of CGI compatibility sounds
> >a bit ridiculous to me) Regards Antoine.
>
> I still use CGI for the odd one-off, testing, prototyping, etc., and
> it's by far the easiest thing to deploy on a lot of web hosts.

Really? Isn't that the kind of thing for which wsgiref should be the preferred
choice?
As for deployment, why would anyone recommend using CGI in production?

Regards

Antoine.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

hidura
In reply to this post by rdsteph@mac.com
> CGI is by far the quickest and easiest way to write and deploy very simple web site scripts. As you move to improve Python for important industrial strength web programming, why not also continue to support quick and dirty web interactivity scripts?
Because CGI is an old fashion way to make the things and is very different from the strength web programming. I don't say that we have to abandon the easy way but wsgi provides an easy way to work and with the PEP-3333 will be able in Py3k so CGI will be no useless.

El , Ron Stephens <[hidden email]> escribió:

> CGI is by far the quickest and easiest way to write and deploy very simple web site scripts. As you move to improve Python for important industrial strength web programming, why not also continue to support quick and dirty web interactivity scripts?
>
>
>
> Ron Stephens
>
>
>
> Sent from my iPhone
>
>
>
> On Jan 4, 2011, at 7:53 AM, "P.J. Eby" [hidden email]> wrote:
>
>
>
> > At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
>
> >> Alice Bevan McGregor writes: > > [1] http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of the "CGI server example" in this new SWGI spec? This is 2011, and we should promote modern idioms, not encourage people to do 1995 Web programming. 10 years ago, CGI was already frown upon. (and even the idea that WSGI should provide some kind of CGI compatibility sounds a bit ridiculous to me) Regards Antoine.
>
> >
>
> > I still use CGI for the odd one-off, testing, prototyping, etc., and it's by far the easiest thing to deploy on a lot of web hosts.  Hell, even Google App Engine *emulates* CGI in its default deployment configuration, IIRC.  So it's not exactly obsolete.
>
> >
>
> > Also, the main purpose of the example is to show what a web server developer needs to do to hook up their own piping to provide WSGI services...  and most web server developers have something like CGI code already lying around, or at least know what CGI looks like.
>
> >
>
> >
>
> >
>
> >
>
> >> _______________________________________________ Web-SIG mailing list [hidden email] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/pje%40telecommunity.com
>
> >
>
> > _______________________________________________
>
> > Web-SIG mailing list
>
> > [hidden email]
>
> > Web SIG: http://www.python.org/sigs/web-sig
>
> > Unsubscribe: http://mail.python.org/mailman/options/web-sig/rdsteph%40mac.com
>
> _______________________________________________
>
> Web-SIG mailing list
>
> [hidden email]
>
> Web SIG: http://www.python.org/sigs/web-sig
>
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/hidura%40gmail.com
>
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

Eric Larson-5
In reply to this post by Antoine Pitrou
At Tue, 4 Jan 2011 17:19:48 +0000 (UTC),
Antoine Pitrou wrote:

>
> P.J. Eby <pje@...> writes:
> >
> > At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
> > >Alice Bevan­McGregor <alice@...> writes: > > [1]
> > >http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
> > >the "CGI server example" in this new SWGI spec? This is 2011, and we
> > >should promote modern idioms, not encourage people to do 1995 Web
> > >programming. 10 years ago, CGI was already frown upon. (and even the
> > >idea that WSGI should provide some kind of CGI compatibility sounds
> > >a bit ridiculous to me) Regards Antoine.
> >
> > I still use CGI for the odd one-off, testing, prototyping, etc., and
> > it's by far the easiest thing to deploy on a lot of web hosts.
>
> Really? Isn't that the kind of thing for which wsgiref should be the preferred
> choice?
> As for deployment, why would anyone recommend using CGI in production?
>
> Regards
>
> Antoine.
>

It is important to recognize that "production" doesn't necessarily
have to be some ultra powerful server somewhere that is central to
some organization. A simple server running Apache with CGI is just as
valid a production environment as an EC2 cluster. This is especially
true when you are the only person using the application and
requirements are minimal. The point being that in terms of the
specification, it should be plausible a person could use a WSGI
application without heavy server requirements. Shared hosting is the
obvious example here but minimal virtual machines may also fit into
this category.


Eric Larson

>
> _______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/eric%40ionrock.org
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

Klaus Bremer
In reply to this post by hidura

CGI may be old fashioned, but in my opinion Ron got the point. And for simple applications CGI is fast enough.
I don't want to miss this option.

Klaus.

--

Am 04.01.2011 um 18:57 schrieb [hidden email]:

> Because CGI is an old fashion way to make the things and is very different from the strength web programming. I don't say that we have to abandon the easy way but wsgi provides an easy way to work and with the PEP-3333 will be able in Py3k so CGI will be no useless.
>
> El , Ron Stephens <[hidden email]> escribió:
> > CGI is by far the quickest and easiest way to write and deploy very simple web site scripts. As you move to improve Python for important industrial strength web programming, why not also continue to support quick and dirty web interactivity scripts?
> >
> >
> >
> > Ron Stephens
> >
> >
> >
> > Sent from my iPhone
> >
> >
> >
> > On Jan 4, 2011, at 7:53 AM, "P.J. Eby" [hidden email]> wrote:
> >
> >
> >
> > > At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
> >
> > >> Alice Bevan McGregor writes: > > [1] http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of the "CGI server example" in this new SWGI spec? This is 2011, and we should promote modern idioms, not encourage people to do 1995 Web programming. 10 years ago, CGI was already frown upon. (and even the idea that WSGI should provide some kind of CGI compatibility sounds a bit ridiculous to me) Regards Antoine.
> >
> > >
> >
> > > I still use CGI for the odd one-off, testing, prototyping, etc., and it's by far the easiest thing to deploy on a lot of web hosts.  Hell, even Google App Engine *emulates* CGI in its default deployment configuration, IIRC.  So it's not exactly obsolete.
> >
> > >
> >
> > > Also, the main purpose of the example is to show what a web server developer needs to do to hook up their own piping to provide WSGI services...  and most web server developers have something like CGI code already lying around, or at least know what CGI looks like.
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> > >> _______________________________________________ Web-SIG mailing list [hidden email] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/pje%40telecommunity.com
> >
> > >
> >
> > > _______________________________________________
> >
> > > Web-SIG mailing list
> >
> > > [hidden email]
> >
> > > Web SIG: http://www.python.org/sigs/web-sig
> >
> > > Unsubscribe: http://mail.python.org/mailman/options/web-sig/rdsteph%40mac.com
> >
> > _______________________________________________
> >
> > Web-SIG mailing list
> >
> > [hidden email]
> >
> > Web SIG: http://www.python.org/sigs/web-sig
> >
> > Unsubscribe: http://mail.python.org/mailman/options/web-sig/hidura%40gmail.com
> >
> >_______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/klaus.bremer%40bmcct.de

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

Antoine Pitrou
In reply to this post by Eric Larson-5
Eric Larson <eric@...> writes:

> It is important to recognize that "production" doesn't necessarily
> have to be some ultra powerful server somewhere that is central to
> some organization. A simple server running Apache with CGI is just as
> valid a production environment as an EC2 cluster. This is especially
> true when you are the only person using the application and
> requirements are minimal. The point being that in terms of the
> specification, it should be plausible a person could use a WSGI
> application without heavy server requirements. Shared hosting is the
> obvious example here but minimal virtual machines may also fit into
> this category.

That sounds backwards. If you use a shared hosting or some minimal virtual
machine, you are much more concerned about resource consumption than if you have
ample processing power (*). And indeed, big companies often have wasteful setups
(including overblown and/or badly-written applications/frameworks/etc.) while
individuals and non-profits have to optimize their setups much more carefully.

(*) (and not only *you* are concerned, but so is your host ;-))

Also, the latency imposed by CGI to each request (due to startup overhead) can
be a problem not only for resource consumption but also for responsiveness and
therefore usability of the Web site/app. Why not use wsgiref directly, at least?

(for the record, the leading Web scripting language, PHP, has moved away from
CGI and standardized on mod_php eons ago)

Regards

Antoine.


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

Guido van Rossum
In reply to this post by PJ Eby
On Tue, Jan 4, 2011 at 7:53 AM, P.J. Eby <[hidden email]> wrote:

> At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
>> Alice Bevan­McGregor <alice@...> writes: > > [1] http:://bit.ly/e7rtI6 So,
>> while we are at it, could we get rid of the "CGI server example" in this new
>> SWGI spec? This is 2011, and we should promote modern idioms, not encourage
>> people to do 1995 Web programming. 10 years ago, CGI was already frown upon.
>> (and even the idea that WSGI should provide some kind of CGI compatibility
>> sounds a bit ridiculous to me) Regards Antoine.
>
> I still use CGI for the odd one-off, testing, prototyping, etc., and it's by
> far the easiest thing to deploy on a lot of web hosts.  Hell, even Google
> App Engine *emulates* CGI in its default deployment configuration, IIRC.  So
> it's not exactly obsolete.

Right. Note that App Engine does not copy the full CGI mechanism -- it
doesn't start a new process for each request. But it does use
os.environ to set the request parameters for each request. However, in
practice, all but the simplest test apps use a custom WSGI bridge, and
we are considering dropping CGI in favor of WSGI in a future version
of the App Engine runtime.

--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

hidura
In reply to this post by Eric Larson-5
I used wsgi and have my app on a shared server and runs excelent,
better than if was using cgi, that cause me a lot of headache with the
incompatiblities with Py3k.

2011/1/4, Eric Larson <[hidden email]>:

> At Tue, 4 Jan 2011 17:19:48 +0000 (UTC),
> Antoine Pitrou wrote:
>>
>> P.J. Eby <pje@...> writes:
>> >
>> > At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
>> > >Alice Bevan­McGregor <alice@...> writes: > > [1]
>> > >http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
>> > >the "CGI server example" in this new SWGI spec? This is 2011, and we
>> > >should promote modern idioms, not encourage people to do 1995 Web
>> > >programming. 10 years ago, CGI was already frown upon. (and even the
>> > >idea that WSGI should provide some kind of CGI compatibility sounds
>> > >a bit ridiculous to me) Regards Antoine.
>> >
>> > I still use CGI for the odd one-off, testing, prototyping, etc., and
>> > it's by far the easiest thing to deploy on a lot of web hosts.
>>
>> Really? Isn't that the kind of thing for which wsgiref should be the
>> preferred
>> choice?
>> As for deployment, why would anyone recommend using CGI in production?
>>
>> Regards
>>
>> Antoine.
>>
>
> It is important to recognize that "production" doesn't necessarily
> have to be some ultra powerful server somewhere that is central to
> some organization. A simple server running Apache with CGI is just as
> valid a production environment as an EC2 cluster. This is especially
> true when you are the only person using the application and
> requirements are minimal. The point being that in terms of the
> specification, it should be plausible a person could use a WSGI
> application without heavy server requirements. Shared hosting is the
> obvious example here but minimal virtual machines may also fit into
> this category.
>
>
> Eric Larson
>
>>
>> _______________________________________________
>> Web-SIG mailing list
>> [hidden email]
>> Web SIG: http://www.python.org/sigs/web-sig
>> Unsubscribe:
>> http://mail.python.org/mailman/options/web-sig/eric%40ionrock.org
> _______________________________________________
> Web-SIG mailing list
> [hidden email]
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> http://mail.python.org/mailman/options/web-sig/hidura%40gmail.com
>

--
Enviado desde mi dispositivo móvil

Diego I. Hidalgo D.
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

hidura
>Right. Note that App Engine does not copy the full CGI mechanism -- it
>doesn't start a new process for each request. But it does use
>os.environ to set the request parameters for each request. However, in
>practice, all but the simplest test apps use a custom WSGI bridge, and
>we are considering dropping CGI in favor of WSGI in a future version
>of the App Engine runtime.

I can give the code of my lib that i use as bridge with my server on
Py3k with wsgi that is small but replace very well the work of cgi
in some functions and the community can start with that, and is
simple to make it run.

El , Hidura <[hidden email]> escribió:

> I used wsgi and have my app on a shared server and runs excelent,
>
> better than if was using cgi, that cause me a lot of headache with the
>
> incompatiblities with Py3k.
>
>
>
> 2011/1/4, Eric Larson [hidden email]>:
>
> > At Tue, 4 Jan 2011 17:19:48 +0000 (UTC),
>
> > Antoine Pitrou wrote:
>
> >>
>
> >> P.J. Eby writes:
>
> >> >
>
> >> > At 12:43 PM 1/4/2011 +0000, Antoine Pitrou wrote:
>
> >> > >Alice Bevan­McGregor writes: > > [1]
>
> >> > >http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
>
> >> > >the "CGI server example" in this new SWGI spec? This is 2011, and we
>
> >> > >should promote modern idioms, not encourage people to do 1995 Web
>
> >> > >programming. 10 years ago, CGI was already frown upon. (and even the
>
> >> > >idea that WSGI should provide some kind of CGI compatibility sounds
>
> >> > >a bit ridiculous to me) Regards Antoine.
>
> >> >
>
> >> > I still use CGI for the odd one-off, testing, prototyping, etc., and
>
> >> > it's by far the easiest thing to deploy on a lot of web hosts.
>
> >>
>
> >> Really? Isn't that the kind of thing for which wsgiref should be the
>
> >> preferred
>
> >> choice?
>
> >> As for deployment, why would anyone recommend using CGI in production?
>
> >>
>
> >> Regards
>
> >>
>
> >> Antoine.
>
> >>
>
> >
>
> > It is important to recognize that "production" doesn't necessarily
>
> > have to be some ultra powerful server somewhere that is central to
>
> > some organization. A simple server running Apache with CGI is just as
>
> > valid a production environment as an EC2 cluster. This is especially
>
> > true when you are the only person using the application and
>
> > requirements are minimal. The point being that in terms of the
>
> > specification, it should be plausible a person could use a WSGI
>
> > application without heavy server requirements. Shared hosting is the
>
> > obvious example here but minimal virtual machines may also fit into
>
> > this category.
>
> >
>
> >
>
> > Eric Larson
>
> >
>
> >>
>
> >> _______________________________________________
>
> >> Web-SIG mailing list
>
> >> [hidden email]
>
> >> Web SIG: http://www.python.org/sigs/web-sig
>
> >> Unsubscribe:
>
> >> http://mail.python.org/mailman/options/web-sig/eric%40ionrock.org
>
> > _______________________________________________
>
> > Web-SIG mailing list
>
> > [hidden email]
>
> > Web SIG: http://www.python.org/sigs/web-sig
>
> > Unsubscribe:
>
> > http://mail.python.org/mailman/options/web-sig/hidura%40gmail.com
>
> >
>
>
>
> --
>
> Enviado desde mi dispositivo móvil
>
>
>
> Diego I. Hidalgo D.
>
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: CGI in PEP 444

James Y Knight
In reply to this post by Antoine Pitrou
On Jan 4, 2011, at 1:24 PM, Antoine Pitrou wrote:
> (for the record, the leading Web scripting language, PHP, has moved away from
> CGI and standardized on mod_php eons ago)

Yet also still offers a cgi if you want to use that instead.

CGI is a wonderful lowest-common-denominator. It's a great option for little scripts which are infrequently run.

I don't get the hatred: it's old (this is a GOOD thing!), it works, and everything supports it.

Back to the subject of this thread: A simple CGI server is useful because it's simple enough that you can include it in the spec, to demonstrate how to handle various bits of WSGI. And anyone writing a webserver understands CGI, and can understand that. A complete HTTP implementation would not be simple enough to write into the spec.

Obviously if you write your app to the WSGI spec, you will want to deploy it on an existing HTTP server or cgi wrapper in the stdlib (or whatever else you want, that's the whole point!). Users aren't going to be copy and pasting the text from the spec to run their app. So, really, what's the problem?

James
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
123