> This is certainly a controversial idea, and one that is frequently > criticised, often in this manner. Although I don't *agree* with the > criticism, I don't object to it ;). Its design rationale should be > better documented, and for that I apologize.
Grin. There's no need to apologise - Twisted is a fantastic (free) system, and better documented than a whole lot of APIs I've had the (mis)fortune to use over the years. > > However, although you may want a "user object" that is different than > the page -- and in that case the top-level page should probably wrap > that object -- the term "avatar" has a specific meaning. To be an > avatar for HTTP, you must implement IResource. > > You can disagree about whether this is the most generally useful design, > but it *is* the specific design to which the jargon term "avatar" refers > in the context of cred. Trying to re-define it so that it doesn't mean > that makes an already confusing topic even more difficult to discuss. > So please don't. That was not my intention, and if you feel I've made a confusing statement then I'm sorry - let it be purged from the internets! By way of explanation regarding the basis of my thinking; the majority of the large web-app work I've done to this point is on Zope. It of course has the basic architecture of a tree of object instances. It would be unusual (to the best of my, admittedly not encyclopedic, knowledge) to spawn new instances of the entire page/object hierarchy when a user logs in. Instead the object-publisher walks the same tree, applying both zopes inbuilt permissions and making the user info available to pages/code on the request object. It's a model I like (along with a lot of other things about Zope, offset by some things I despise) and will have to give some thought as to whether to emulate or move away from. _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
