WSGIKit.notes

Thursday, March 24, 2005

TITLE OF PAPER: WSGIKit: Utilizing WSGI as a platform for inter-framework cooperation
URL OF PRESENTATION: <http://ianbicking.org/docs/pycon2005>
PRESENTED BY: Ian Bicking
REPRESENTING: Imaginary Landscape

CONFERENCE: PyCon 2005
DATE: Wednesday, March 23, 2005
LOCATION: GWU Cafritz Conference Center, Marvin Theatre

--------------------------------------------------------------------------
REAL-TIME NOTES / ANNOTATIONS OF THE PAPER:
{If you've contributed, add your name, e-mail & URL at the bottom}

The Problem: Too many Web Framework choices
...deja vu...

Solution 1
    Choose the One True Framework (to rule them all...)
Solution 2
    ___
Solution 3
    The web?  What's the web?  Use some other language for that crap.
    "When all you have is a hammer, screws are stupid"

Need a practical solution
    Can't keep continuing along the current path
    Can't abandon current developers/projects
    Support legacy interfaces, and future new frameworks
    Mitigate the cost of diversity

Try to turn our diversity of frameworks into a good thing, rather than a mess
Lets not get lapped by Ruby (if we haven't been already) !

Work from bottom up
    Start at the lowest layer (the server)

=== WSGIKit (PEP 333) ===
 * Started with a webware application (legacy API)
 * Refactored into a component-based architecture with WSGI


Need a basic foundation for all toolkits
 * We can probably agree on all the boring basic stuff
 * Don't commit to one model (threads vs. events)
 * asthetic value not important because frameworks will be built around it.
   need a complete framework

WSGI connects "servers" to "applications"
 * For many values of 'server' and 'application'
   * Twisted, Apache, Zope, Webware, etc.
 * Already a foundational API
 * PEP standard API like the DB API
 * Presents a standard environment
   * Accessible dictionary of all standard CGI variables, etc.
   * Users can add their own keys to the dictionary for providing new
     functionality (e.g. sessions)
 * WSGI is well specified
 * Multi-tier (n-tier)
  * Arbitrary levels of middleware, if desired
 * WSGI not pretty, but therein lies the extensibility - fancy APIs
   are purposely left out.
 





--------------------------------------------------------------------------
REFERENCES: {as documents / sites are referenced add them below}

--------------------------------------------------------------------------
QUOTES:



--------------------------------------------------------------------------
CONTRIBUTORS: {add your name, e-mail address and URL below}
Nick Bastin (nick.bastin@gmail.com) <http://www.nickbastin.com>
Linden Wright (lwright@mac.com)
Andy Gross (andy@akamai.com) <http://argv0.net>

--------------------------------------------------------------------------
E-MAIL BOUNCEBACK: {add your e-mail address separated by commas }



--------------------------------------------------------------------------
NOTES ON / KEY TO THIS TEMPLATE:
A headline (like a field in a database) will be CAPITALISED
    This differentiates from the text that follows
A variable that you can change will be surrounded by _underscores_
    Spaces in variables are also replaced with under_scores
    This allows people to select the whole variable with a simple double-click
A tool-tip is lower case and surrounded by {curly brackets / parentheses}
    These supply helpful contextual information.

--------------------------------------------------------------------------
Copyright shared between all the participants unless otherwise stated...