« URL-rewriting in CherryPy 2.1Somebody's finally using text/x-json »

Agenda topics for CherryPy 2.2 roadmap meeting


Permalink 03:35:00 pm, by fumanchu Email , 262 words   English (US)
Categories: CherryPy

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...


Comment from: Kevin Dangoor [Visitor] · http://www.blueskyonmars.com

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.

10/26/05 @ 21:28
Comment from: fumanchu [Member] Email

I'd be very interested to know what that "monkeypatch" is (and how you think we can obviate it) before or during the meeting.

10/26/05 @ 22:34
Comment from: Kevin Dangoor [Visitor] · http://www.blueskyonmars.com

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.

10/27/05 @ 07:03
Comment from: Ian Bicking [Visitor] · http://blog.ianbicking.org

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.

10/28/05 @ 09:11

Leave a comment

Your email address will not be revealed on this site.

Your URL will be displayed.

Please enter the phrase "I am a real human." in the textbox above.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)
October 2018
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      


The requested Blog doesn't exist any more!

XML Feeds

powered by b2evolution free blog software