On 09:05 am, p.mayers@imperial.ac.uk wrote:
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.
Thank you :)
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!
I'll go get the memory hole.
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.
The key thing to realize about Twisted's resources is that they are "light". They are very small objects that just implement a few methods. By contrast - Zope, and lots of other traditional web frameworks, have resources that are "heavy" - you need to back them with an object in a database, a file on disk, or some other similar construct. These two models don't have to be an either-or proposition. The IResource-as-avatar design is, to my mind, the most flexible way to implement differing authenticated content, but one often does not want to make use of all that flexibility. It is certainly a "design pattern" in web-based Twisted apps to have an underlying common resource hierarchy that the authenticated hierarchy is a lightweight "overlay" onto. In other words, the IResource avatar is *how* you implement authentication, it is not necessarily *what* you implement for an authenticated system. It is lower-level than the resource hierarchy that Zope provides. However, I think it's an important level of the infrastructure to be able to plug in to: I'm not sure if Zope does this, but there are certainly plenty of web-based systems that *require* you to present exactly the same hierarchy of objects (or files, or scripts), albeit with perhaps different behavior, to different users.
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.
You might have a look at the resource hierarchy in the Divmod application server, Mantissa, and see how that maps to your expectations. (It may be a bit under-documented, so feel free to ask questions if something is not obvious.)