[Twisted-web] simple guard question

[glyph at divmod.com]

On 09:05 am, p.mayers at 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.)