Python Notes

Thursday, October 07, 2004

Publishing classes or instances?

Python is an excellent language for web development, as it can be easily verified by the number of options when it comes to web-enabled frameworks. Most frameworks implement a object publisher -- a piece of software that finds the correct object and activates it upon request. Each object is 'published', or associated with some part of the site.

All object publishers -- or at least, all that I'm aware of -- work with object instances. In this scheme, all HTTP requests to some part of the site are directed to an instance that handles it. Such requests are short lived, and in many cases, all the data is valid for a single request. Multiple threads may be running, though; session data for each call is separate, and web frameworks provide some way to find the correct data for the session that did the request, and for the thread where the server is running.

After pondering a while about it, it seems to me that a better way to design the system would be to publish object classes. At each request, the web framework would create a new instance of the class to handle the request. This technique seems interesting because it clearly dedicates one instance for each request. It incurs on the additional cost of instantiation, but this should not be so high, at least for low volume non-critical apps -- the type of apps I'm working with for the small business market.

I'm now trying to do some tests with the concept, using the upcoming CherryPy2 framework. I've already adapted the object publisher to look for classes, and to instantiate and dispatch requests to them. It was a pretty minor change. It has one potential advantage, in that I can handle long-running persistent sessions using clever Javascript hacks such as the ones used by GMail. In these apps, each client connection has a long-running component, doing direct data requests to the server (using plain HTML, XML or SOAP) in the background. This component is hidden in the browser in a non-visible frame, and it does not have to be reloaded every time the page is refreshed. It's an interesting technique already used for highly interactive websites.

38 Comments:

Post a Comment

<< Home