This is more a philosophical question about what is the better way to organize a Zope utility. The feeling of acquisition is a nice one, and is a joy to program with, but there seems to be one scenario that troubles me a little. Am I correct in assuming that objects and their properties(if they are allowed them) are static, or shared in their nature. I.e. : 2 people accessing the same object at the same time are sharing that object, and therefore can potentially collide if they both are able to execute a method that changes this object, say a property such as language. To overcome this I reorganized things such that shared objects could only have constant like properties that only a manager can change and then created a session object, which is just a rather boring ZClass that can hold onto session variables so that I don't have to keep passing them around as form variables, since this is the interface that the public user has. Maybe this is not the right way to do it, maybe there are better ways of letting someone move around with session variables. I thought perhaps cookies would be a better thing, except that people can turn these off. The next problem then is that it is easy enough getting people to login through a particular node so that I can set a sheet up for them before redirecting them to another part of the Zope environment, but there is no way to ensure they have to log out so that I can throw the sheet away. Hmm, yes cookies sound better. The more important point is that I have used methods in their fullest sense of acquisition ... I use redirects to activate a method in the correct part of the Zope environment so that it acquires what it needs and creates instances of various ZClasses as required. These methods are obviously reasonably close to root of the hierarchy, just so they can be thrown to many places. I want to be able to restrict where these can be thrown to stop people playing around with their own urls and creating bad objects in the wrong places. Anyone have any thoughts on these problems? regards Matt Bion