| « URL-rewriting in CherryPy 2.1 | Somebody's finally using text/x-json » |
Agenda topics for CherryPy 2.2 roadmap meeting
10/26/05
Agenda topics for CherryPy 2.2 roadmap meeting
There will be an IRC meeting for the CherryPy 2.2 roadmap on Thursday, 6pm GMT. Things I want to discuss (most-important items first):
- Merging the /requestobj branch to trunk. This branch merges the cherrypy.request object with the _cphttptools.Request object. This is just generally a good idea, and will make the code cleaner. It could also be a first step toward...
- Allowing subclassing of the Request object in order to handle various dispatch schemes.
- An API for HTTP-method dispatch, including ways to encourage developers of new apps to care about idempotency.
- Ticket #356: Formalize server.environment as a set of config defaults
- Multiple apps in a single process, including...
- Arbitrary mount points for applications
- Possible solutions to #362 (guaranteed filter methods). One such solution might involve...
- Alternatives to the filter system--see if there's any way to declare customizations (which the app developer sees as frozen, and critical to the app) in code
- Formalize the intended uses of request attributes (like browserUrl, base, path, querystring, etc.). There is some confusion in the codebase regarding when those should be, and are currently, rewritten. This will the inform...
- Fixing the VirtualHostFilter (to inspect the Host header)
- Better HTTP content-negotiation (Accept-* and Vary headers)
- Better content caching (Expires header, etc)
- Not really for discussion, but I want to get my mod_python WSGI gateway to work as well as mpcp on Unix
More as I think of them...
4 comments
Your list looks basically the same as mine. It would take care of some things I want for TurboGears and should get rid of a crazy monkeypatch that I have.
I'd be very interested to know what that "monkeypatch" is (and how you think we can obviate it) before or during the meeting.
At the moment, TurboGears has 3 monkeypatches for CherryPy. One is a change to the autoreloader so that it takes a top-level package to watch for changes instead of looking at everything in sys.modules. (This was key for dealing with zipped Eggs).
The second is that I changed getObjFromPath so that I could keep track of "application root" objects as I was traversing. That allows the URL generation function to know where "/" is.
The third is a change to check_port to add a timeout for systems that have packet filters (we exchanged a couple of emails on this a couple days back), so they don't wait 1 minute before starting up.
By "Multiple apps in a single process" do you mean (hopefully) ticket #145?
I suspect you don't mean "idempotency", but rather "safety". Lost of unsafe GET links are idempotent (e.g., a /delete?id=10 link).
Paste does application mounting as middleware, in http://svn.pythonpaste.org/Paste/trunk/paste/urlmap.py , using just well-defined ways of dispatching to applications. A similar technique might be good for CherryPy, doing application dispatching just from a high-level, without any confusing attributes or whatnot. From some of the problems I've seen people report related to incoming URLs, I suspect CherryPy is using something more ad hoc. Seeing where such ad hoc techniques went in Zope... well, you don't want to go there (VirtualHostMonster and all that... blech!) Paste uses the well-defined SCRIPT_NAME and PATH_INFO for everything, with no exceptions, and it's worked well (I certainly have encountered the opposite situation more than once in Webware, with a confusing array of slightly-overlapping views of the URL space, and it's hard to keep track of).
I think subclassing the Request object is a bad idea. Subclassing any core object -- and you don't get more core than the request -- is a bad method for extension, IMHO.
Anyway, those are just some of my thoughts, some of which I care about (#145), and some which might just be helpful.
Oh, and a monkeypatch is when one Python package pokes at functions and objects in another Python package to fix some behavior. It's like a runtime patch of the system.
Comment feed for this postLeave a comment
