On 10/20/06, Michael Watkins  wrote:
> * Sells, Fred wrote [2006-10-20 09:50:00 -0400]:
> > Is Quixote a viable solution in the Ajax environment?
>
> Sure. AJAX is just http, with Javascript on the client, as you know.

AJAX is "in" Javascript, and these are typically static files,
although you could build them on the fly if you had a reason to.
Javascript makes asynchronous requests to the server: obviously
Quixote can handle this.

TurboGears has built-in support for turning any web method into a JSON
method, so that you can return a dict of values rather than an HTML
page. In Quixote I think you just change the MIME type of the response
and return the JSON value as a string.  I would put AJAX methods in a
separate directory; I never saw much point in combined HTML/JSON URLs:
normally your asynchronous requests are doing specialized tasks that
don't need a full-blown webpage, right?

> > Is mod_python itself a viable solution with Quixote, I've just started using
> > it.  Am intimidated by alternatives that require installing and
> > administering another server (SCGI?) when we have a VERY SMALL IT group.

SCGI is not a bid bad scary server. It's a small simple Apache module
that serializes the CGI environment variables and POST input into a
form that can be transmitted to another process via a socket. On
Quixote's side the "server" unpacks these values, builds a Request
object, and calls the Publisher. So it's essentially the same as
pickle but not Python-specific. It's not any more complex or less
reliable than mod_python. Quixote's SCGI implementation has one server
process and delegates to a pool of subprocesses to process the
requests -- the same way Apache handles requests. Having a standalone
server process makes it easier to monitor what it's doing and restart
it when you wish, without having to guess how it's interacting with
Apache's internals.

If you don't want to use mod_scgi for some reason, there's an scgi.cgi
program in the SCGI distribution which does the same thing.  It's
written in C, and I've written a Python equivalent which is...
somewhere.

> Speaking as a former Quixote user (I still maintain a couple 'legacy' Quixote
> apps), might I suggest that you consider also "QP", a closely related cousin
> to Quixote.

I haven't used QP but it's certainly worth looking at if you're
choosing between the two. It's more modern than Quixote and has better
Unicode support (QPY rather than htmltext), and has built-in support
for managing multiple sites.  I need to make a version of htmltext
that uses QPY, so hopefully that will close that gap soon.  The one
thing I don't like about QP is you have to modify a file in the
package to list your sites: that goes against my philosophy of having
generic packages that you configure when you invoke them rather than
building user-specific stuff in the package.  But if you can live with
that, QP has some advantages.  I'm sticking with Quixote because I'm
maintaining several production sites in it and have to train other
programmers new to Python, and my next big jump will probably be to a
megaframework if/when there's a compelling reason to.

If you need persistent sessions, you'll want the session2 package
which is seprarate from Quixote.  I guess QP has sessions built in via
Durus.  Durus is a good database and I use it, although not for
sessions.

--
Mike Orr