Dropping CGI support?

[Jonas Borgström]

Hi,

What about dropping CGI support for 0.12?
It was the first Trac frontend but nowadays it's too slow for almost any
use and also one of the hardest to get working.
/ Jonas

[Alec Thomas]

+1

As a transitional thing we could move it to trac-hacks.

2008/7/2 Jonas Borgström <jo...@edgewall.com>:

--
And the next thing you know, you're at the zoo, shaving a yak,
all so you can wax your car.

[Markus Fuchs]

> What about dropping CGI support for 0.12?
> It was the first Trac frontend but nowadays it's too slow for
> almost any use and also one of the hardest to get working.

I'm wondering what frontend you would recommend IIS users when dropping CGI
support. AFAIK there's no WSGI ISAPI extension out there that you could use
for production use, so CGI is the only choice.

Cheers,
Markus

[Noah Kantrowitz]

tracd + proxy. Or use the new FCGI support assuming they didn't screw
it up.

--Noah

[Graham Dumpleton]

Although you may drop explicit CGI bridge code from Trac, that doesn't
mean you can't use it under CGI. You could quite happily use a CGI-
WSGI bridge, one of which I believe is included in wsgiref module from
Python 2.5 onwards. If not, a workable CGI-WSGI bridge is described in
the WSGI PEP.

Technically you could also drop explicit mod_python bridge code and
use a mod_python-WSGI bridge instead. Same for FASTCGI or any other
explicit bridge code that exists, all you technically need is WSGI
support and you then use appropriate WSGI bridge for whatever hosting
mechanism is used. The overhead of the WSGI bridge is generally
insignificant.

Anyway, dropping support for any beside CGI is probably a bit more
premature at this point as WSGI still hasn't got as much mind share as
some of the other solutions. Anything to encourage people not to use
CGI sounds reasonable, but as stated, with a CGI-WSGI bridge they
could always still do it if they want to.

Graham

[Noah Kantrowitz]

That is what we do already: http://trac.edgewall.org/browser/trunk/trac/web/cgi_frontend.py
Trac is a purely WSGI-based app, all frontends are just wrappers for
that.

Really dropping CGI support is more a matter of removing it from the
docs and telling people we won't help them if they use CGI, I wouldn't
mind leaving the code to support since it is pretty minimal. There are
sometimes reasons to use CGI (suExec and the like, for example), but
it should be clear it exists only for expert users really.

--Noah