1. The Core Session Tracking looks like it will be really helpful. I AM BLOWN AWAY BY THE QUALITY OF THE DOCUMENTATION. Congratulations for making really readable, easy to use installation and use instructions. Part of the reason I'm so blown away, of course, is that the quality of this documentation is so very much superior to most of the existing documentation. The author obviously put himself in the position of someone who didn't know anything about the topic, and wrote the documentation to satisfy this person (i.e. me). Thanks!

Thanks for the kudos!

2. Question. The interface to the session data object, requiring set/get calls to get key/value pairs seems a little inconsistent with the very simple existing interfaces for other zope namespaces. As a newbie, I admit to being very confused about namespaces in zope, and the GOOD THING about the core session tracking is that it is very clear that you're accessing a variable from that scope. There's no way you can accidently acquire something else. On the other hand, the ability to access the session variables with simple variable references seems like it would be a win (especially if they were safely qualified by the session object). I really just want to do something like "SESSION.varname". Is this something that can be wrapped on top of the existing interface?

Yes. I will think about this, because I'm not very happy about the current data object interface. It definitely needs work. I had orignally intended to use a straight mapping (dictionary) interface, but we've got a lot of DTML code that looks like "_[[['']]]" already, so I didn't want to perpetuate the problem by encouraging __getitem__ and __setitem__ access in DTML. :-) That's why you can't do SESSION['varname'] right now, and instead you need to use SESSION.get('varname'). This lends itself better to things like: <dtml-with sessionmanager> <dtml-with getSessionData> <dtml-var "get('a')"> </dtml-with> </dtml-with> which potentially has the same rhythm as <dtml-with sessionmanager> <dtml-with getSessionData> <dtml-call "set('a', 'b')"> </dtml-with> </dtml-with> as opposed to the following combination <dtml-with sessionmanager> <dtml-let SESSION=getSessionData> <dtml-var "SESSION['a']"> </dtml-with> </dtml-with> vs <dtml-with sessionmanager> <dtml-let SESSION=getSessionData> <dtml-call "SESSION.set('a', 'b')"> </dtml-with> </dtml-with> The enforced parity in the former set of DTML snippets between get and set methods makes the data object a little easier to explain to non-Python people. And it's easier to explain to Python people that the data object isn't a mapping than to explain to non-Python people what a mapping is in the first place and how and why they need to do all the funny quoting and bracketing. :-) The __getattr__ interface for retrieval and .set() for insertion might work better, however, because it doesn't require quoting at all. It still has the problem that you may want to use an indirect variable name, in which case you'd need to use something like "_.getattr(sessiondataobject, aname)", which is just as evil. You also can't do assignments in DTML, so you'd still need a 'set' method. A potential rhythm, however, might look like: <dtml-with sessionmanager> <dtml-with getSessionData> <dtml-call "set('a', 'b')"> </dtml-with> </dtml-with> and <dtml-with sessionmanager> <dtml-with getSessionData> <dtml-var a> </dtml-with> </dtml-with> I sorta like it the original way now that I've written that down. :-) It's easier to explain, AFAICS.