PEP 333: Python Web Server Gateway Interface v1.0

Discussion in 'Python' started by Phillip J. Eby, Aug 27, 2004.

  1. PEP: 333
    Title: Python Web Server Gateway Interface v1.0
    Version: $Revision: 1.1 $
    Last-Modified: $Date: 2004/08/27 17:30:09 $
    Author: Phillip J. Eby <pje at telecommunity.com>
    Discussions-To: Python Web-SIG <web-sig at python.org>
    Status: Draft
    Type: Informational
    Content-Type: text/x-rst
    Created: 07-Dec-2003
    Post-History: 07-Dec-2003, 08-Aug-2004, 20-Aug-2004, 27-Aug-2004


    Abstract
    ========

    This document specifies a proposed standard interface between web
    servers and Python web applications or frameworks, to promote web
    application portability across a variety of web servers.


    Rationale and Goals
    ===================

    Python currently boasts a wide variety of web application frameworks,
    such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web -- to
    name just a few [1]_. This wide variety of choices can be a problem
    for new Python users, because generally speaking, their choice of web
    framework will limit their choice of usable web servers, and vice
    versa.

    By contrast, although Java has just as many web application frameworks
    available, Java's "servlet" API makes it possible for applications
    written with any Java web application framework to run in any web
    server that supports the servlet API.

    The availability and widespread use of such an API in web servers for
    Python -- whether those servers are written in Python (e.g. Medusa),
    embed Python (e.g. mod_python), or invoke Python via a gateway
    protocol (e.g. CGI, FastCGI, etc.) -- would separate choice of
    framework from choice of web server, freeing users to choose a pairing
    that suits them, while freeing framework and server developers to
    focus on their preferred area of specialization.

    This PEP, therefore, proposes a simple and universal interface between
    web servers and web applications or frameworks: the Python Web Server
    Gateway Interface (WSGI).

    But the mere existence of a WSGI spec does nothing to address the
    existing state of servers and frameworks for Python web applications.
    Server and framework authors and maintainers must actually implement
    WSGI for there to be any effect.

    However, since no existing servers or frameworks support WSGI, there
    is little immediate reward for an author who implements WSGI support.
    Thus, WSGI *must* be easy to implement, so that an author's initial
    investment in the interface can be reasonably low.

    Thus, simplicity of implementation on *both* the server and framework
    sides of the interface is absolutely critical to the utility of the
    WSGI interface, and is therefore the principal criterion for any
    design decisions.

    Note, however, that simplicity of implementation for a framework
    author is not the same thing as ease of use for a web application
    author. WSGI presents an absolutely "no frills" interface to the
    framework author, because bells and whistles like response objects and
    cookie handling would just get in the way of existing frameworks'
    handling of these issues. Again, the goal of WSGI is to facilitate
    easy interconnection of existing servers and applications or
    frameworks, not to create a new web framework.

    Note also that this goal precludes WSGI from requiring anything that
    is not already available in deployed versions of Python. Therefore,
    new standard library modules are not proposed or required by this
    specification, and nothing in WSGI requires a Python version greater
    than 2.2.2. (It would be a good idea, however, for future versions
    of Python to include support for this interface in web servers
    provided by the standard library.)

    In addition to ease of implementation for existing and future
    frameworks and servers, it should also be easy to create request
    preprocessors, response postprocessors, and other WSGI-based
    "middleware" components that look like an application to their
    containing server, while acting as a server for their contained
    applications.

    If middleware can be both simple and robust, and WSGI is widely
    available in servers and frameworks, it allows for the possibility
    of an entirely new kind of Python web application framework: one
    consisting of loosely-coupled WSGI middleware components. Indeed,
    existing framework authors may even choose to refactor their
    frameworks' existing services to be provided in this way, becoming
    more like libraries used with WSGI, and less like monolithic
    frameworks. This would then allow application developers to choose
    "best-of-breed" components for specific functionality, rather than
    having to commit to all the pros and cons of a single framework.

    Of course, as of this writing, that day is doubtless quite far off.
    In the meantime, it is a sufficient short-term goal for WSGI to
    enable the use of any framework with any server.

    Finally, it should be mentioned that the current version of WSGI
    does not prescribe any particular mechanism for "deploying" an
    application for use with a web server or server gateway. At the
    present time, this is necessarily implementation-defined by the
    server or gateway. After a sufficient number of servers and
    frameworks have implemented WSGI to provide field experience with
    varying deployment requirements, it may make sense to create
    another PEP, describing a deployment standard for WSGI servers and
    application frameworks.


    [Remainder truncated due to python-list posting size limit; please see:

    http://python.org/peps/pep-0333.html

    for remaining text.]
     
    Phillip J. Eby, Aug 27, 2004
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andreas Klemt
    Replies:
    0
    Views:
    562
    Andreas Klemt
    Jul 15, 2003
  2. Replies:
    0
    Views:
    303
  3. John Smith

    computing t = pow(-11.5, .333)

    John Smith, May 16, 2006, in forum: C Programming
    Replies:
    42
    Views:
    1,128
  4. John
    Replies:
    0
    Views:
    1,067
  5. John
    Replies:
    0
    Views:
    1,072
Loading...

Share This Page