[Trimmed down the Cc list to those I know will be interested.]
Ian Bicking wrote:
>> I looked briefly at the source and saw it's not a simple straightforward
>> task.
>> - wsgikit.cgiserver seems to be the only adapter, akin to
>> quixote.servers.cgi_server . Nothing fast enough for production use
>> unless you believe in FastCGI (which I don't).
>
> It's the only one really included, just because it doesn't have a Real
> Home. wsgi-server can handle the WSGIUtils server, a "console" server
> (which dumps one page to stdout), a CGI-generating "server" (creates a
> CGI script), and used to support Twisted. But Twisted web 2 got native
> WSGI support, and I haven't tracked it down since then. I would like to
> include all other interesting servers (at least stubs for them), but I
> don't think it's hard, and if it isn't hard I feel okay putting it off ;)
I guess the first thing that's needed is a HOWTO explaining all these
alternatives, where to get them and install them, and which ones work with
which.
I downloaded TwistedSumo-2005-03-22 and grepped for wsgi but there wasn't
anything. I saw a note from you on twisted-web with a reply saying it's
in twisted.web2 . Is that a separate package?
>> - The Session middleware may be usable. It saves to files akin to
>> DirMapping.
>
> It's actually not that good, but I expect to integrate this session
> middleware soon: http://www.saddi.com/software/py-lib/#Session
Actually, our Session object is used like an instance rather than a
dictionary, and it has .user/.get_user()/.set_user(), so we'd have to
support those somehow. And people are used to subclassing Session (and
Request) to provide extra attributes or for inter-method communication.
>> - The URL Parser middleware is prob'ly not applicable since we don't
>> look for specific URLs in the filesystem, and we must allow ._q_traverse
>> to be overridden at any "directory" level.
>
> Probably not applicable though potentially the URL parser could be used
> to get to the Quixote parser, if that happened to be useful for
> deployment.
>
> I was reluctant to do this at first, but I'm thinking a URL mapper
> middleware would be useful, so you might do (in the configuration):
>
> urls['/webmail'] = config('path/to/webmail.conf')
>
> Where webmail.conf contains all the configuration, including the type of
> application. For instance, this starts up a webkit app implicitly when
> present in the configuration:
>
> webkit_dir = 'path/to/something'
>
> So I'd imagine:
>
> quixote_root = 'my_app.root.object'
>
> Or something like that. There should be multiple ways to deploy and
> compose applications in a single process.
>
> Ideally I'd like to see one fairly general object publisher (/URL
> parser) included in WSGIKit, where Quixote applications would either
> subclass that publisher or pass in some configuration variables to get
> it to act like Quixote's publisher.
Quixote (Qx) applications tend to have one class per directory rather than
per servlet. The classes can be made autonomous and relocatable, which
means they can fit into larger units (Qx or non-Qx). Parsing below the
directory URL is not needed because each directory has a
._q_traverse(list_of_following_components) => string|htmltext
method that handles it. The default implementation looks for a method
named after the next component and calls *its* ._q_traverse of there are
further components, or if there are no further components it just calls
the method and returns the result. But you can override ._q_traverse
completely if you want to do something different.
> Do Quixote objects that are published inherit from a single class? If
> not, then the publisher probably has to wrap the published object just
> before passing off control to that object, and the wrapper would create
> the request and response objects and make sure they get flushed properly
> and whatnot.
Directories usually inherit from Directory, although they may be any
object with a compatible ._q_traverse method/function.
The level above is the
Publisher.process_request(request) => response
method. The URL parsing is simple:
'/'.split(url)
The Publisher also delegates the session handling and performs error
handling. PublishError(public_msg, private_msg) results in the public
message to the user and both messages in the log. Any other exceptions
call cgitb, with variations for security. We're currently in debate about
how much of the Publisher would be left if all the middleware components
were factored out. Maybe it would only split the URL and call the
traversal metnod. Another problem is decoupling the Session from the
Publisher, since the Session currently depends on it. Not ideal if you
think the Publisher might disappear.
We may have to decide how far to support custom Publisher/Session/Request
subclasses, or maybe have two WSGI implementations: a monolithic one for
highly customized sites, and a middleware'd one for generic sites.
One thing I don't understand is, WSGI seems to require both parts to be in
the same process, since you can't pickle an open file object. I thought
WSGI would replace SCGI, but with that limitation it can't. It would have
to operate on the application side of it. It makes the WSGI adapter seem
very small and perhaps not worth the trouble, since you're essentially
just repackaging the environment dictionary twice and not getting at the
real problem, which is the darn mod_* to Python interface, and mod_*
modules that break when you need them or suddenly won't compile. What can
WSGI middleware do that SCGI middleware couldn't do?