From exogen at gmail.com Mon Jan 3 05:04:37 2005 From: exogen at gmail.com (Brian Beck) Date: Mon Jan 3 05:10:26 2005 Subject: [Web-SIG] Application framework shootout? Message-ID: Hi. I've recently started a project which is intended to become a pretty big web application. So far I've been winging it with my own simple system using mod_python, Vampire and SQLObject, but I would hardly call it a framework. Could someone summarize (or direct me to a summary) of the advantages/disadvantages (in comparison to each other) of frameworks like PEAK, WebWare, nevow, and anything else applicable? I've read a little about each but still can't put my finger on it. Is she geared toward a specific type of application? Any help would be appreciated. -- Brian Beck Adventurer of the First Order From exogen at gmail.com Mon Jan 3 05:13:08 2005 From: exogen at gmail.com (Brian Beck) Date: Mon Jan 3 05:20:24 2005 Subject: [Web-SIG] Re: Application framework shootout? In-Reply-To: References: Message-ID: Brian Beck wrote: > little about each but still can't put my finger on it. Is she geared > toward a specific type of application? Whoops. That should read 'Is *each* geared toward a specific type of application?' -- Brian Beck Adventurer of the First Order From titus at caltech.edu Mon Jan 3 08:33:58 2005 From: titus at caltech.edu (Titus Brown) Date: Mon Jan 3 08:34:06 2005 Subject: [Web-SIG] Application framework shootout? In-Reply-To: References: Message-ID: <20050103073358.GB18773@caltech.edu> On Sun, Jan 02, 2005 at 11:04:37PM -0500, Brian Beck wrote: -> Hi. -> -> I've recently started a project which is intended to become a pretty big -> web application. So far I've been winging it with my own simple system -> using mod_python, Vampire and SQLObject, but I would hardly call it a -> framework. -> -> Could someone summarize (or direct me to a summary) of the -> advantages/disadvantages (in comparison to each other) of frameworks -> like PEAK, WebWare, nevow, and anything else applicable? I've read a -> little about each but still can't put my finger on it. Is each geared -> toward a specific type of application? -> -> Any help would be appreciated. Hi, Brian, you can look at Ian Bicking's framework shootout here: http://colorstudy.com/docs/shootout.html I also like the PyWebOff, although it is not yet complete: http://pyre.third-bit.com/pyweb/index.html If you find any additional sites I'd be interested in hearing about them... cheers, --titus From remi at cherrypy.org Mon Jan 3 18:53:43 2005 From: remi at cherrypy.org (Remi Delon) Date: Mon Jan 3 18:53:47 2005 Subject: [Web-SIG] Ann: CherryPy-2.0-beta released In-Reply-To: References: Message-ID: <41D986A7.3080306@cherrypy.org> Hello everyone, I am happy to announce the release of CherryPy-2.0-beta. CherryPy-2 is a pythonic, object-oriented web development framework. CherryPy-2 is a redesign of CherryPy-1 (the unpythonic features have been removed): no more compilation step, pure python source code (no more "CherryClass") Here is a sample Hello, World in CherryPy-2: # from cherrypy import cpg # class HelloWorld: # @cpg.expose # def index(self): # return "Hello world!" # cpg.root = HelloWorld() # cpg.server.start() Main properties: - this code starts a multi-threaded HTTP server that dispatches requests to methods - requests like "http://domain/dir/page?arg1=val1&arg2=val2" are mapped to "dir.page(arg1='val1', arg2='val2')" - requests are mapped to an object tree that is "mounted" on cpg.root (for instance: "cpg.root.user", "cpg.root.user.remi", ...) - method must be explicitely exposed with a decorator "@cpg.expose" (or "index.exposed = True" for Python-2.3) - methods can return a generator instead of a string (useful when generating big pages) Here is a non-exhaustive list of CherryPy-2 features: multi-threaded HTTP server, XML-RPC server, sessions, form handling, authentication, unicode support, gzip-compression, virtual hosting, WSGI adapter (experimental) The design of CherryPy-2 allows to easily write/use pluggable "filters" or "modules": - filters perform operations on the request/response such as gzip-compression or string encoding - modules are web applications (like a blog or a web forum) than can be easily "mounted" anywhere you want in your website CherryPy-2 is already used in production by several sites and is supported by an active community. Remi. http://www.cherrypy.org PS: Is the "Python Web Framework Shootout" (http://www.colorstudy.com/docs/shootout.html) still being maintained ? The part about CherryPy is quite out-of-date so it would be nice if it could be updated for CherryPy-2 (I can provide some content if needed) From ianb at colorstudy.com Mon Jan 3 19:24:03 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Jan 3 19:24:45 2005 Subject: [Web-SIG] Ann: CherryPy-2.0-beta released In-Reply-To: <41D986A7.3080306@cherrypy.org> References: <41D986A7.3080306@cherrypy.org> Message-ID: <41D98DC3.1080706@colorstudy.com> Remi Delon wrote: > Here is a non-exhaustive list of CherryPy-2 features: > multi-threaded HTTP server, XML-RPC server, sessions, form handling, > authentication, unicode support, gzip-compression, virtual hosting, > WSGI adapter (experimental) I'm curious, what does the WSGI invocation look like? Or, what would you like it to look like? I ask since it's kind of an open issue at this point. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From remi at cherrypy.org Mon Jan 3 19:50:57 2005 From: remi at cherrypy.org (Remi Delon) Date: Mon Jan 3 19:51:05 2005 Subject: [Web-SIG] Ann: CherryPy-2.0-beta released In-Reply-To: <41D98DC3.1080706@colorstudy.com> References: <41D986A7.3080306@cherrypy.org> <41D98DC3.1080706@colorstudy.com> Message-ID: <41D99411.9040809@cherrypy.org> Ian, >> Here is a non-exhaustive list of CherryPy-2 features: >> multi-threaded HTTP server, XML-RPC server, sessions, form handling, >> authentication, unicode support, gzip-compression, virtual hosting, >> WSGI adapter (experimental) > > > I'm curious, what does the WSGI invocation look like? Or, what would > you like it to look like? I ask since it's kind of an open issue at > this point. Here is a some sample code that uses a CherryPy WSGI app and the "WSGIServer" from PEAK: # from cherrypy import cpg, wsgiapp # class Root: # def index(self, name = "world"): # return "Hello, %s" % name # index.exposed = True # cpg.root = Root() # # # if __name__ == "__main__": # wsgiapp.init() # Read the CherryPy config file and initialize some variables # server_address = ("", 8000) # httpd = WSGIServer(server_address, WSGIRequestHandler) # httpd.set_app(wsgiapp.wsgiApp) # sa = httpd.socket.getsockname() # print "Serving HTTP on", sa[0], "port", sa[1], "..." # httpd.serve_forever() Remi From ianb at colorstudy.com Mon Jan 3 22:36:36 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Jan 3 22:37:24 2005 Subject: [Web-SIG] Re: Ann: CherryPy-2.0-beta released In-Reply-To: <1104785774.524707.214290@f14g2000cwb.googlegroups.com> References: <1104774372.943278.302050@f14g2000cwb.googlegroups.com> <1104783888.664232.72720@f14g2000cwb.googlegroups.com> <1104785774.524707.214290@f14g2000cwb.googlegroups.com> Message-ID: <41D9BAE4.6050003@colorstudy.com> remi@cherrypy.org wrote: > Well, you can easily run CherryPy behind Apache (see > http://trac.cherrypy.org/cgi-bin/trac.cgi/wiki/BehindApache). > Since CherryPy provides a WSGI interface (although it's still > experimental), you can also run your CherryPy app with any > WSGI-compatible HTTP server (although I don't really see any advantage > to doing this). In the future when more WSGI environments are deployed, I think the benefits will be nice. For instance, under WSGIKit (http://svn.colorstudy.com/trunk/WSGIKit) you should be able to create a file: # cherry_app.py: from cherrypy import cpg, wsgiapp from my_cherry_app import root_instance cpg.root = root_instance wsgiapp.init() # This variable name is automatically picked up: application = wsgiapp.wsgiApp Then your application would be available under cherry_app/ (wherever you happened to put that file in the URL space). Note that WSGIKit isn't a server itself, just a set of middleware that delegates to different applications. It occurs to me that it would be considerably cleaner if it looked more like this: from cherrypy import wsgiapp from my_cherry_app import root_instance application = wsgiapp.Application(my_cheery_app) Otherwise you can only run one CherryPy application in a process...? That would be very limiting. Anyway, the idea is you can deploy a CherryPy-based application fairly easily alongside other WSGI Python web applications. The particulars still need some work -- I don't like the little Python file used to put the pieces together -- but I think it's a good direction. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Tue Jan 11 20:22:54 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Tue Jan 11 20:23:16 2005 Subject: [Web-SIG] OT: Exception report library Message-ID: <41E4278E.4010201@colorstudy.com> I originally sent this to comp.lang.python, but I didn't get much response, so I'm hoping someone here has some opinion on exception reports; this isn't specifically web related, but I am looking to use it in WSGIKit (and elsewhere) and I'm hoping someone here has an opinion. I've been using one of several systems to catch unexpected exceptions and log them (e.g., write to a file, display on web page, email me, etc). But many are built into a particular system, or have an interesting but incomplete set of features. E.g., many web frameworks have exception reporters (and the stdlib includes cgitb), but I want to handle non-web exceptions in the same way as exceptions from web requests, and that's not generally easy. So, I'm figuring there should be some generic library that does this. Does anyone have experience with one they could recommend? PyCrash comes to mind: http://pycrash.sourceforge.net/, though the XML output doesn't excite me (but the post-mortem debugging data is nice). py.test makes nice tracebacks with extra data as well, and cgitb is another option, though I've found the cgitb code to be poorly factored for reusability when I've looked at it in the past. Zope includes an otherwise-Zope-neutral ExceptionFormatter, which isn't terribly exciting, except that it does look for __traceback_info__ local variables and create reports with those inlined. Maybe there's something better that's packaged as part of a larger framework? Does anyone have good or bad experience with PyCrash? Localized application extensibility is really useful to me as well; for instance, in a web application I like to know who the logged-in user is, and all sorts of environment information, and there's no way to acquire that information that is common to all the environments I'd like this to work in. On the reporting end configuration and hooks are also really useful; e.g., there's no general way to display an exception report on a web page, so a web framework would have to hook into it in some way as well. (Maybe this isn't as true with WSGI, but I don't think there's any libraries written for WSGI anyway) So I'm kind of looking for the best-of-breed for this particular functionality; adding the reports and logging is easy, it's really the nice traceback that I'm hoping to find. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From rodsenra at gpr.com.br Tue Jan 11 20:56:17 2005 From: rodsenra at gpr.com.br (Rodrigo Dias Arruda Senra) Date: Tue Jan 11 20:55:17 2005 Subject: [Web-SIG] OT: Exception report library In-Reply-To: <41E4278E.4010201@colorstudy.com> References: <41E4278E.4010201@colorstudy.com> Message-ID: <41E42F61.7070204@gpr.com.br> Ian Bicking wrote: > I've been using one of several systems to catch unexpected exceptions > and log them (e.g., write to a file, display on web page, email me, > etc). But many are built into a particular system, or have an > interesting but incomplete set of features. E.g., many web frameworks > have exception reporters (and the stdlib includes cgitb), but I want to > handle non-web exceptions in the same way as exceptions from web > requests, and that's not generally easy. > > So, I'm figuring there should be some generic library that does this. I re-invented that wheel many times, so +1 ;o) > Does anyone have experience with one they could recommend? Nope. But, influenced from recent discussions in py-dev I believe such tool shoud use an adaption-based framework, using a report protocol boundable to several adaptable backends. > Localized application extensibility is really useful to me as well; for > instance, in a web application I like to know who the logged-in user is, > and all sorts of environment information, and there's no way to acquire > that information that is common to all the environments I'd like this to > work in. I can offer some develop/doc/test time to this effort. best regards, Senra -- Rodrigo Senra MSc Computer Engineer rodsenra@gpr.com.br GPr Sistemas Ltda http://www.gpr.com.br From ianb at colorstudy.com Tue Jan 18 19:31:31 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Tue Jan 18 19:32:11 2005 Subject: [Web-SIG] Web-SIG related PyCon sprint? Message-ID: <41ED5603.8010403@colorstudy.com> Is anyone interested in doing a sprint at PyCon on something related to Web-SIG? It could be WSGI-related (e.g., adapting some frameworks), or something built on top of WSGI, or deployment configuration, or even something more vaguely related to the web. I'm not 100% sure I'll be able to come to the sprint, or what days, but then the specific sprints effect that as well. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Tue Jan 18 19:41:28 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Tue Jan 18 19:42:04 2005 Subject: [Web-SIG] Web-SIG related PyCon sprint? In-Reply-To: <41ED5603.8010403@colorstudy.com> References: <41ED5603.8010403@colorstudy.com> Message-ID: <41ED5858.1000904@colorstudy.com> Forgot to mention: Sprint Wiki: http://www.python.org/moin/PyConDC2005/Sprints - Sprinting A sprint is a multi-day session of intense development organized around extreme programming (XP) ideas such as pair programming. There will be four days, March 19-22, before the regular conference to sprint on a variety of projects. Ian Bicking wrote: > Is anyone interested in doing a sprint at PyCon on something related to > Web-SIG? It could be WSGI-related (e.g., adapting some frameworks), or > something built on top of WSGI, or deployment configuration, or even > something more vaguely related to the web. > > I'm not 100% sure I'll be able to come to the sprint, or what days, but > then the specific sprints effect that as well. > From floydophone at gmail.com Wed Jan 19 13:51:23 2005 From: floydophone at gmail.com (Peter Hunt) Date: Wed Jan 19 13:51:26 2005 Subject: [Web-SIG] twisted_wsgi.py license Message-ID: <6654eac40501190451379b0135@mail.gmail.com> Due to many requests, I'm announcing that the twisted_wsgi.py library is released under the MIT license. This basically means you can do whatever you want with it. Happy hacking! Peter Hunt From david at sundayta.com Sat Jan 29 00:33:41 2005 From: david at sundayta.com (David Warnock) Date: Sat Jan 29 00:34:05 2005 Subject: [Web-SIG] WSGI Servers Message-ID: <41FACBD5.1070200@sundayta.com> Hi, Everyone else may disagree but it seems to me that servers are where the remaining big gap is for wsgi. What I want is to be able to pester hosting services to provide a really good, fast, reliable wsgi standards compliant server. I don't care if the application deployment is non standard, as long as there is one and I can do it without shell or root access. I don't care if I have not got plugins, filters etc standardised yet (as long as I will have some way to add them without shell or root access). This wsgi server must work with python 2.2 or later and it must work with apache 1 or 2. The rest of my pythonic toolkit is starting to look excellent with - CherryPy2 for url mapping, sessions, request and response, filters, is wsgi compliant - sqlObject for dbms access - Kid for templating - ElementTree for xml (with cElementTree where it is possible) - py.test as the best unit testing tool - openanything.py from Mark Pilgrim, dive into python as a standard http client. http://diveintopython.org/http_web_services/index.html - Ian Bickings wsgi.config also looks like it will soon be in the toolkit. Now I just need to get some standard project practices sorted out and then can really move, at least we could if hosting were sorted. Note that all these are wonderfully simple tools that do a limited set of tasks and do them well and flexibly making them easy to assemble together. I much prefer this to the big frameworks - although for other larger projects plone is a good if rather heavyweight choice BUT hosting services are my key problem. I want to plug some dynamic features into very low end hosting (under $50 per year including domain) and so far have only only python with cgi available. Have I missed something, anyone know what I can push hosting services towards? Thanks Dave From titus at caltech.edu Sun Jan 30 03:44:47 2005 From: titus at caltech.edu (Titus Brown) Date: Sun Jan 30 03:44:50 2005 Subject: [Web-SIG] Fun with WSGI -- commenting middleware. Message-ID: <20050130024447.GA10409@caltech.edu> Hi all, I sat down today to hack out a simple commenting system for HTML articles, and ended up using WSGI to implement a pipe-style solution. You can see the results at http://www.idyll.org/~t/articles.cgi/ This CGI script serves HTML files from a directory hierarchy. Anyone can attach a comment to any HTML file served by the script. Briefly, the solution consists of two WSGI apps, one a client called "wsgiServeFiles" and the other a middleware app called "wsgiComment". The command app = wsgiServeFiles(directory) creates a client app that will serve files out of the given directory according to fairly simple rules. The command new_app = wsgiComment(app) creates a wrapped client app that will allow you to comment paths under the given app. So, to create the site above, all I did was use the WSGI CGI implementation and run the following command: run_with_cgi(wsgiComment(wsgiServeFiles('/u/t/articles/text'))) The source code is pretty simple. I wanted something that would run via CGI and require nothing other than local filesystem access and a Python installation (no databases, etc.) The code's available at http://www.idyll.org/~t/articles.cgi/source/ It's still pretty hacky, and comments are appreciated. Note that the commenting system should work for any WSGI client, although I haven't tried it for anything else yet. cheers, --titus From ianb at colorstudy.com Mon Jan 31 02:36:30 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Jan 31 02:36:24 2005 Subject: [Web-SIG] WSGI Servers In-Reply-To: <41FACBD5.1070200@sundayta.com> References: <41FACBD5.1070200@sundayta.com> Message-ID: <41FD8B9E.7010401@colorstudy.com> David Warnock wrote: > Everyone else may disagree but it seems to me that servers are where the > remaining big gap is for wsgi. Oh, I'd probably agree, there's a lot of things on the server end of WSGI which are unanswered. I guess this list that I wrote a while ago covers some of the things like I'd live: http://blog.ianbicking.org/an-ideal-python-web-programming-environment.html WSGI only helps in that it separates concerns -- many of these issues could be addressed purely on the server side, for any framework. > What I want is to be able to pester hosting services to provide a really > good, fast, reliable wsgi standards compliant server. I don't care if > the application deployment is non standard, as long as there is one and > I can do it without shell or root access. I don't care if I have not got > plugins, filters etc standardised yet (as long as I will have some way > to add them without shell or root access). I think this is pretty hard, though clearly worth the effort. From a hosting perspective: 1) It should work with a single Apache server with multiple clients. Obviously it's better with a single server per client -- e.g., clients can have their server run as different users (instead of everyone sharing the nobody account). But that's not the typical way commodity hosts are set up. 2) It should work with Apache 1.3, since that's used heavily, even if Apache 2 has some potentially useful capabilities. 3) It shouldn't require manual server restarts or resets, edited code needs to update itself transparently. 4) It needs some automatic monitoring, e.g., if you have an infinite loop or some memory explosion, it has to degrade gracefully -- aborting the request, and continue to serve other things for the client. Maybe there'd be some collateral damage for the client -- a few other lost requests -- but other clients can't be effected. 5) It shouldn't need complicated Apache configuration; preferably nothing, or configuration that can go in an .htaccess file. 6) It shouldn't be horribly inefficient. CGI is great except for 6. mod_python isn't very good for 1-4, AFAIK. Separate threaded processes (like Zope or Webware) are problematic for 3 and 4. In theory something FastCGI-based should be able to do this. I don't know of any commodity hosters that support FastCGI, though maybe even now you could use one of the CGI->FastCGI adapters, let the host kill processes as they will but reuse processes to the degree possible. (Or, if not FastCGI, something like it -- if you are using a CGI gateway it doesn't matter if you are using a standard.) Oh, but wait: 7) Not require shell access or a compiler. There's actually a good chance you could get away with this, finding a precompiled FastCGI CGI script that would work and uploading it to the cgi-bin directory, though your URLs will look kind of bad (barring a host that allows rewrite directives in .htaccess files). Still, it's not very easy; could it be made easy with a smart enough installer? Or, there's the possibility that FastCGI could be utilitized in a robust enough way to handle all this, and hosts could support it with good enough instructions and with enough user demand. In that model, maybe you could just drop an appropriate file into your site and make it work. Or, something other than FastCGI, maybe as an Apache module. Not mod_python, since the idea is to run in a separate process, and mostly do what FastCGI is supposed to do, but maybe in an easier-to-understand and easier-to-maintain way. Or, mod_python made to look more like mod_php, that is, more robust and partitioned. I think this might require changes to the Python interpreter itself, so I don't know much about feasibility. I also don't know a lot about mod_python, so maybe it's better this way than I think. I see it like mod_perl, which despite its age generally isn't available on commodity hosts AFAIK. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From stephen.thorne at gmail.com Mon Jan 31 07:55:22 2005 From: stephen.thorne at gmail.com (Stephen Thorne) Date: Mon Jan 31 07:55:25 2005 Subject: [Web-SIG] WSGI Servers In-Reply-To: <41FACBD5.1070200@sundayta.com> References: <41FACBD5.1070200@sundayta.com> Message-ID: <3e8ca5c80501302255344db343@mail.gmail.com> On Fri, 28 Jan 2005 23:33:41 +0000, David Warnock wrote: > Hi, > > Everyone else may disagree but it seems to me that servers are where the > remaining big gap is for wsgi. > > What I want is to be able to pester hosting services to provide a really > good, fast, reliable wsgi standards compliant server. I don't care if > the application deployment is non standard, as long as there is one and > I can do it without shell or root access. I don't care if I have not got > plugins, filters etc standardised yet (as long as I will have some way > to add them without shell or root access). > > This wsgi server must work with python 2.2 or later and it must work > with apache 1 or 2. > > The rest of my pythonic toolkit is starting to look excellent with > > - CherryPy2 for url mapping, sessions, request and response, filters, is > wsgi compliant > > - sqlObject for dbms access > > - Kid for templating > > - ElementTree for xml (with cElementTree where it is possible) > > - py.test as the best unit testing tool > > - openanything.py from Mark Pilgrim, dive into python as a standard http > client. http://diveintopython.org/http_web_services/index.html > > - Ian Bickings wsgi.config also looks like it will soon be in the toolkit. put all of this in an .rpm and .deb and you're laughing. Hosting providers don't want to spend hours installing vague software off dozens of sites. Make it simple, make it easy, make ti just work. Stephen. From james at pythonweb.org Mon Jan 31 19:34:57 2005 From: james at pythonweb.org (James Gardner) Date: Mon Jan 31 19:35:09 2005 Subject: [Web-SIG] Python Web Modules - Version 0.5.0 Message-ID: <41FE7A51.1010205@pythonweb.org> Hello All, I'd like to announce the release of the Python Web Modules 0.5.0. This development release brings WSGI support to the modules. * Web Server Gateway Interface support - auth, error, database and session middleware and a WSGI Server. * Licensed under the LGPL after discussions on the mailing list (but also includes software under other open source licenses which are probably LGPL compatible). * Database layer supports foreign keys, joins and a pure Python database. * New coding structure focused on environments and drivers. * Documentation in various formats including PDF and CHM (Microsoft HTML Help) * Many bug fixes. http://www.pythonweb.org/ Download and have a play What are the Web Modules? ------------------------- The Python Web Modules are a suite of simple and easy to use Python components designed to allow developers to write Python CGI scripts or web applications with SQL databases, sessions, templates, email and authorisation functionality. A key part of the project is the creation of documentation and examples to allow developers with less time or experience to begin Python web programming without having to read all the sources and comments from the very beginning. The modules can easily be used on shared web hosting accounts running Apache and Python for example or with the built in webserver. They are designed to be easily accessible to beginners or developers currently using PHP or Perl whilst also offering lower level APIs for experts to create powerful dynamic websites. Key features include: * web.wsgi - Full Web Server Gateway Interface Support * web.auth - Identification handling. Users may have multiple access levels to multiple applications. Sign in handling is built in. * web.session - Persistence using cookie or URL based session IDs allowing any object which can be pickled to be stored. * web.form - HTML Form generation and user input handling. Field objects available for HTML fields and the main Python types including date and time objects. Values returned as Python objects. * web.database - Portable SQL syntax, DB-API interface and database abstraction layer supporting MySQL, SQLite, SnakeSQL for cross-database programming. Types are converted. Multiple return formats including dict, tuple and object. * web.database.object - Object-relational mapper similar to SQLObject allowing transparent database manipulation using dictionary-like objects in Python code built on web.database. One and many to many mappings and automatic HTML form generation for editing records. * web.error - Enhanced error handling based on the principles of the cgitb module. Handlers for file storage, browser output or email notifications and more. * web.template - Support for Cheetah, XYAPUT and Dreamweaver MX templates. * web.mail - Quickly send plain text or HTML emails. * web.image - Generate 2D pie, bar and scatter graphs in a variety of image formats. * web.xml - Simple XSL Transform. * web.environment - Create an environment for the applications. * datetime - Python 2.3 date handling compatibility module for Python 2.2. Web Modules Links ----------------- Website: http://www.pythonweb.org/ News: http://www.pythonweb.org/projects/news.html Documentation: http://www.pythonweb.org/projects/webmodules/doc/0.5.0 Mailing list: http://lists.sourceforge.net/mailman/listinfo/lemon-webmodules Download: http://www.pythonweb.org/projects/webmodules/release/0.5.0 Best wishes, James -- James Gardner http://www.pythonweb.org From ianb at colorstudy.com Mon Jan 31 19:49:45 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Jan 31 19:51:02 2005 Subject: [Web-SIG] Fun with WSGI -- commenting middleware. In-Reply-To: <20050130024447.GA10409@caltech.edu> References: <20050130024447.GA10409@caltech.edu> Message-ID: <41FE7DC9.3080100@colorstudy.com> Titus Brown wrote: > Hi all, > > I sat down today to hack out a simple commenting system for HTML > articles, and ended up using WSGI to implement a pipe-style solution. > > You can see the results at > > http://www.idyll.org/~t/articles.cgi/ > > This CGI script serves HTML files from a directory hierarchy. Anyone > can attach a comment to any HTML file served by the script. Spiffy. It would be neat to plug this into a WSGI application that served as a proxy (redisplaying pages fetched from another location). Then you could point it at the Python documentation and get that php.net-like commenting that people are always asking for; it would probably be good to make the commenting more granular, but it's interesting to be able to develop the different parts so separately. Actually, I was just going to convert this silly little web-based image viewer I have to WSGI, and with this I could get a free commenting system. Hmm... -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Mon Jan 31 20:14:36 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Mon Jan 31 20:15:50 2005 Subject: [Web-SIG] Python Web Modules - Version 0.5.0 In-Reply-To: <41FE7A51.1010205@pythonweb.org> References: <41FE7A51.1010205@pythonweb.org> Message-ID: <41FE839C.4030007@colorstudy.com> James Gardner wrote: > Hello All, > > I'd like to announce the release of the Python Web Modules 0.5.0. > This development release brings WSGI support to the modules. > > * Web Server Gateway Interface support - auth, error, database and session > middleware and a WSGI Server. Cool, good to see more of this kind of stuff. A couple of notes: web.wsgi.cgi: is this safe when a piece of middleware changes QUERY_STRING or otherwise rewrites the request? You can test for this by saving the QUERY_STRING that you originally parsed alongside the resulting FieldStorage, and then reparsing if they don't match. You can even test for matching with "is", since you're really checking for modifications instead of equality. The same should be possible for wsgi.input and POST requests. web.wsgi.session: I'd like to have some sort of standard for these objects, at least some aspects. Not the details of storage, but mostly access; along the lines of web.session.manager and/or .store. I'm not sure how I feel about the manager with multiple applications, each of which has a store -- I feel like this should be part of the configuration somehow, which isn't necessarily part of the standard user-visible API. web.wsgi.error: one standard I'd like for middleware would be some key you could set that would indicate that some error handler exists, and applications further down the stack shouldn't catch unexpected exceptions (of course expected exceptions are a different matter). Then the best error handler available would eventually get the error, and process it somehow (e.g., mailing a report, displaying an error, starting a debugger, etc). Anyway, something to think about for this. web.wsgi.auth: I've been thinking lot about this as well, particularly about the external interface. REMOTE_USER seems like a reasonable enough place to put the login information. I'd like to keep authorization and authentication separate -- one middleware determines who you are, another (might) determine if you are allowed access. Frequently only the application really knows if you are authorized, based on logic that's beyond any ability to make it generic. So I was thinking that status codes should be sufficient to communicate authorization: 401 for login required, 403 for forbidden. If you are doing cookie logins (which I generally prefer from a UI perspective) the middleware can translate the 401 into a redirect to the login page. And the 403 can turn into a nicer error page -- a piece of middleware for indicating error pages would also be nice (similar to Apache's ErrorDocument directive). Since there's a huge number of ways to log someone in, keeping these concerns separate seems good. Apache and Zope are good counterexamples where they combined too many aspects of authentication and authorization into one bundle. -- Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org