«

In article <>, Afanasiy wrote:
> CGI, FastCGI, SCGI are not faster than mod_python in my experience and
> straightforward benchmark.

In the case of CGI, yes of course. In the case of FastCGI, your
experience contradicts my own.

> That's all I can really say about it. CGI is not an option for me.

I don't understand why you keep saying "CGI is not an option" when
nobody has suggested that you use it.

On 8 Jul 2003 17:59:12 GMT, Jon Ribbens <jon+>
wrote:


>I don't understand why you keep saying "CGI is not an option" when
>nobody has suggested that you use it.

Ok

On 8 Jul 2003 17:59:12 GMT,
Jon Ribbens <jon+> wrote:
> I don't understand why you keep saying "CGI is not an option" when
> nobody has suggested that you use it.

Jon, there's no point in debating Afanasiy about CGI. He's convinced
packages for Python web programming support are inadequate (*all* of them),
is unable to explain what the problem is or what his requirements are, and
doesn't seem to really understand the subject (e.g. thinking FastCGI is
basically the same as regular CGI). Ignoring him is the best course.

--amk

On Tue, 08 Jul 2003 20:46:53 -0500, "A.M. Kuchling" <> wrote:

>On 8 Jul 2003 17:59:12 GMT,
> Jon Ribbens <jon+> wrote:
>> I don't understand why you keep saying "CGI is not an option" when
>> nobody has suggested that you use it.
>
>Jon, there's no point in debating Afanasiy about CGI. He's convinced
>packages for Python web programming support are inadequate (*all* of them),
>is unable to explain what the problem is or what his requirements are, and
>doesn't seem to really understand the subject (e.g. thinking FastCGI is
>basically the same as regular CGI). Ignoring him is the best course.

Read.

In article <>, A.M. Kuchling wrote:
> Jon, there's no point in debating Afanasiy about CGI. He's convinced
> packages for Python web programming support are inadequate (*all* of them),
> is unable to explain what the problem is or what his requirements are, and
> doesn't seem to really understand the subject (e.g. thinking FastCGI is
> basically the same as regular CGI). Ignoring him is the best course.

Oh, ok, ta

A.M. Kuchling wrote:
> At PyCon, it was generally agreed at the Web programming BoF that the
> authors of the various Python frameworks should all implement the same
> example application so that potential users can compare the resulting
> code. Nothing much has been done on this front since then; we should
> get things moving again by figuring out what the example application
> should be. The Java Pet Store was suggested, but it was pointed out
> that it's a very large application, requiring too much effort for an
> author to do in their spare time.

Ian Bicking did something like this with
http://colorstudy.com/docs/shootout.html with a Wiki as the example
application. If there is interest, I would volunteer to copy this into the
Wiki so that it can be more easily extended. I already got Ian's
permissionto do so, but was so far too lazy for it.

> Let's think about the requirements for an example application:
>
> * Should be implementable in a few evenings
> * Should exercise a reasonable set of features.
> * HTML generation (duh!)
> * Accepting a form
> * Returning non-HTML files (generating a GIF, say)
> * Sessions

* access control


I suggest using
http://www.python.org/cgi-bin/moinmo...ammingShootOut as the entry
point for the specification of the application.

Daniel

On Wed, 2003-07-09 at 10:26, Daniel Dittmar wrote:
> Ian Bicking did something like this with
> http://colorstudy.com/docs/shootout.html with a Wiki as the example
> application. If there is interest, I would volunteer to copy this into the
> Wiki so that it can be more easily extended. I already got Ian's
> permissionto do so, but was so far too lazy for it.

It might be preferable to do this in CVS somewhere -- it would handle
the source files better, and most of the commentary can go in comments.

One of the big problems I also had was installation. Many of the
frameworks require non-trivial Apache configuration, which hinders
experimentation. Actually solving this is significant work, though --
but also something which very much deserves solving.

A SourceForge (or equivalent) project might be a good place to start.

Ian

"A.M. Kuchling" <> wrote in message news:

> The Java Pet Store was suggested, but it was pointed out that it's a very
> large application, requiring too much effort for an author to do in their
> spare time.

But you can see the difference only in larger application. Not
everything scales good when programming in the large is necessary. I
never found that simple benchmarks really helps.


> I think I like the store best, because the first three applications are
> all text-oriented, and the content manager doesn't do much beyond spitting back

Yes, me too. It should be something that is usefull for comparison in
larger commercial applications. And it should have test generators to
check the system under heavy system load.

In article <>,
A.M. Kuchling <> wrote:
>
>That reminds me: there was also a proposal to revive the Web-SIG. Ian,
>anything moving on this front? (My offer to host a list still stands.)

I'd suggest putting it on python.org, so that anyone who who looks at
the mailing lists will find it.
--
Aahz () <*> http://www.pythoncraft.com/

"Not everything in life has a clue in front of it...." --JMS

"A.M. Kuchling" <> writes:
> The Java Pet Store was suggested, but it was pointed out that it's a very
> large application, requiring too much effort for an author to do in their
> spare time.

Heh, the point of doing it in Python is it should take much less time
than doing it in Java .

> * Should be implementable in a few evenings

Good

> * Should exercise a reasonable set of features.
> * HTML generation (duh!)
> * Accepting a form

Accepting a very long form (i.e. megabytes of POST data)

> * Returning non-HTML files (generating a GIF, say)
> * Sessions
> * Uploading a file
> * RDBMS access? (That's more a function of the DB-API module you're
> using, but a framework might provide support for pooling
> connections or something similar.)

Yes, this should be included, lack of a standard DB API module is a
serious Python deficiency and any DB-using app needs to work around
the deficiency somehow.

> * Other suggestions?
>
> Possibilities:
> * A Wiki?
> * A multiple-user weblog?
> * A Slashdot-like discussion board?
> * A simple content manager -- upload files, set permissions on them,
> control access to them, and download them again.
> * A simple browse-a-catalog-and-buy-things store?
> * Other suggestions?

Webmail client