thanks for your suggestion Phil. You have pointed out the main objective of my problem and that is,,

I have created a desktop CALDAV client application. The Client connect to the Caldav server and fetches an object
called account (and it cannot be pickled) which has session information, nonce, authentication information etc. Now my task is to port the Desktop code to web so that everybody can user it.

But there is some problem. This account object should be created once per user session for example, ones user passes the user name, password, server address, then this account should be created and using this account any transaction with the CALDAV server should be done.

Now I have made the Design something like this

                                 MainClass(User Login)
                      Calendar Class (The Root of My application, here the account object should be created and passed to the controller class)
                                  Controller Class(This Class Should have account object that it gets from the Calendar Class and                                                                                                                |                     should manage what kind of views user  want)
                      |                                |                              |
                      |                                |                              |
                      |                                |                              |
                     V                               V                            V
                Month(View)            Week(View)           Day(View)                 

I am new to web development, I am thinking of using the core application of CALDAV client  to integrate with this kind of web view. I have tested mod_python and that did not worked for me.
So, can twisted.web be used in this case, and if yes can you please give me some pointers how to do that.

Thanks in advance

On Wed, Jul 23, 2008 at 9:13 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
The information about the user does not belong in any Resource subclass: a
Resource is a page that can be generated for different users, so it should
only contain information that is the same for all users. Any user specific
data should be fetched via the request object.

This is totally inaccurate. It's perfectly reasonable to store
user-specific data in Resource objects.  "a Resource is a page that
can be generated for different users" is either irrelevant or not
true, I can't tell which. You can dynamically and return Resources
based on which user is making the request.

Now, I'm not sure my favorite abstraction for a user is a string; I'd
probably pass something other than a username to a Resource. Perhaps a
rich object representing the user.

Since this is a common mis-conception (one I suffered from and have now disabused myself of) it's worth discussing.

If my understanding is correct: twisted.cred uses the concept of an "avatar". Avatars (I think...):

 * are protocol objects
 * represent the user

In twisted.web, the Resource *is* the avatar. In twisted.mail.imap, the Mailbox is the avatar. In twisted.conch, the Shell is the avatar (and so on).

I found this initially confusing, because in many web frameworks e.g. Zope, where I came from, the objects representing resources are:

 * long lived
 * the same instances serve >1 HTTP request
 * instantiated at process start time

It's also somewhat confusing because unlike other protocols, HTTP requests are very short-lived. It's worth noting you *can* have long-lived multi-instance t.w.Resource objects.

In twisted, a common design pattern seems to be (I hope; I adopted it...)

 * have your realm return a root Resource i.e. one for "/"
 * attach your User object to that resource
 * have your root resource dynamically create the leaf resources via locateChild or childFactory, then attach the User object
 * when you need user info, get at it via e.g. self.user
 * let the leaf/root objects get GC-ed when the HTTP request is done

I believe changes have been committed to twisted.web making this design pattern even more preferred:


Code which, by the way, I very much like the look of.

Could someone clarify if this is the "right" way of doing things?

Twisted-web mailing list