[Web-SIG] WSGI configuration and character encoding.

[Ian Bicking]

Terrel Shumway wrote:
> I haven't been following this thread closely, but here is my $.02 based 
> on my continuing experience in implementing a Cheetah framework over 
> WSGI and deploying it via CGI and mod_python.
> 
> Ian Bicking wrote:
> 
>> Phillip J. Eby wrote:
>>
>>> Here's what I'm thinking: paths in the file should be allowed to be 
>>> relative to the directory containing the deployment file, and the 
>>> configuration passed to the application or its setup should include 
>>> the path to the deployment file.  The combination of these two things 
>>> would suffice to allow distribution of an application in a largely 
>>> ready-to-deploy form.  The application could always provide 
>>> facilities to edit its own configuration file(s) or the deployment 
>>> configuration.
>>
>>
>>
>> This leads to the question: when would you edit the deployment file? 
>> Besides just using a different directory prefix?
> 
> 
> The "packager" edits the <deployment descriptor> and bundles the code, 
> templates, etc. that the app requires.  This is often a different person 
> from the "programmer" who creates the components.

I expect the packager to have programming skills, even if they aren't
the same person as the application programmer.

> The server administrator or "webmaster" is the person who edits the 
> <server configuration> file to assign a URL space to each app.  The 
> webmaster might have his own middleware to add, e.g. for extra logging, 
> or performance monitoring.

The webmaster may not have programming skills (or at least not Python).
  Though depending on the sophistication of the integration, I'd be okay
with some programming required.  For instance, if you are integrating
your login method with the application's, it might be necessary to do
some programming -- simple login sharing should be easy, but sharing
user metadata and administrative operations (e.g., adding users and the
like) will probably require programming (unless the systems are
specifically meant to work with each other -- i.e., another standardized
interface).

> A given application has a fixed set of requirements, why not just code 
> them up in Python?  Well, I can imagine reasons, but I think we need to 
> start from use cases.
> 
> So here's a use case:
> 
>  > that application can have more or less functionality (depending on 
> how much functionality I expect the parent to have -- e.g., session 
> support).

I'd like this to be automated.  If, for instance, we can standardize the
session interface this should be doable.  The application looks for,
say, session.api_1 (standard session API, version 1).  If it finds it,
it uses it, knowing the interface.  If not, it puts in its own piece of
middleware that provides the API.

Until we standardize that, we'll be doing this stuff ad hoc, but that's
okay -- this is an ongoing process.

> Two core features that are "required" by a Java servlet container are 
> session support, and login support. And every existing container that I 
> know of also supports JSP.

JSP is funny, and not a model widely used for Python (I think).  It
certainly doesn't seem as fundamental in a WSGI model, where URLs aren't
necessarily mapped to files.

That is, I don't think there's any kind of file you can just plop into a
WSGI container and it will display; not even Python source.  There's no
file-like container, and there's no standard URL->object mapping or
configuration.  I'm not entirely sure there should be a standard, at
least not one we expect most people to use... certainly several
frameworks could share implementations, to the degree they act
similarly.  But object publishers (e.g., Quixote, Zope) and file-based
systems (e.g., Webware, Spyce) are going to remain fairly separate.

> These three features -- session, login, templates -- are needed by 
> enough people that I think they should be standard.  (e.g. how difficult 
> would it be to create a wiki if you could rely on the framework for 
> these? -- 80% of the work is done.)
> 
> Another kit that might have broad application is a formkit --  a 
> higher-level way to manage posted form data  -- but that probably 
> doesn't belong in WSGI (PEP), because there are a lot of different ways 
> people want to do it.

I don't think this needs to be part of the request cycle at all -- the
application is always an intermediary there.  It's simply a library.

> Probably ditto for templates. But in python, "you really only have to do 
> it one way".  There should be one (1) easy way to say how a container 
> interacts with a template engine. I'm not sure what that means yet, but 
> I'll think about it.

At first I thought templates should just be a library as well, though it
would be nice if applications could share templating configuration.
I.e., you could indicate a template search path, maybe adding more paths
on a per-application basis, or otherwise fiddling with that path (e.g.,
skinning an application based on URL).  But we can handle that in a
neutral way, i.e., providing a generic configuration system that is
template users can use as they wish (though they'll want to form
conventions about key naming; or we can provide conventions about how to
adapt configurations to different naming schemes).

> e.g. the framework I am building can get template files from different 
> places to easily support skinning. It would be nice to say "get template 
> X and fill it from these variables" without worrying about where X 
> resides in a filesystem or .zip archive. (along the lines of the java 
> ServletContext.getResource*() methods)  If I deploy four applications 
> (Contexts), I want them to share template files 
> (/var/www/sitename/templates/) so the designer can change the look and 
> feel of the whole site at once.  In my case, I also want a set of 
> templates shared among many sites on the same server (/var/www/templates/)
> There should be a standard way for servlet authors to say "this is the 
> 'content' piece that I care about, and here are some styles and <head> 
> content. Now you put it together inside the site-wide templates to 
> create the page."  And it shouldn't matter to the developer whether that 
> sitewide template is implemented with Cheetah or CherryPy or Quixote or 
> ZTP or whatever.

This does make me think templating could participate in the request
cycle, as a filter of sorts.  Right now we're trying to move to SSIs as
a shared templating scheme, at least when we move to Apache 2, because
all our scripts can output SSIs and Apache will evaluate them.  Maybe
not everyone will want SSIs (obviously), but maybe this general pattern
can be used -- one of filtering text.  I don't know what else we can
agree on, especially in environments where everything isn't Python.
This is akin to an XSLT-based templating approach, but of course there
are much better languages than XSLT that we can come up with ;)

If we do it as filtering, we don't have to agree nearly as much about
templating languages or even interfaces.  We just have to agree on a
document format, which somehow seems easier.  We wouldn't even have to
agree that much on document format; if we were using SSIs, we could make
something that transforms document type X into SSIs, and then Apache
does the next step.  This is an N^2 problem, given N kinds of
data/template languages, but at least it offers some kind of solution.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org