On Sun, 2005-02-27 at 03:46 -0500, Stephen Waterbury wrote: [snip everything for brevity] Thanks for sharing this Stephen. It's made me question the realm-portal architecture I've been using. I notice that Stephen creates multiple realms - one for each "service" your application provides. Each realm then has a portal to connect it to the checker(s). That is interesting because the approach I have taken is to have *one* realm for the entire application and a portal for each "service". For instance I might have a single instance of my.app.Realm and one each of my.web.public.Portal, my.web.admin.Portal, my.web.xmlrpc.Portal, my.ftp.Portal etc. The reason I structure my code like this is because I consider the realm to be the "hub" of the application (something I thought the cred HOWTO was hinting at). My realm generally has all sorts of useful attributes, i.e. a ConnectionPool, as well as the application's "global" API. I also anticipated that, one day, my realm instance would need to be more aware of the avatars it had created. Right now, the only issue I have with my singleton realm way of working is that the realm's requestAvatar can get big and tends to look like a switch statement. It has to know about everything going on, even if it doesn't much care about the avatar once the method returns. Stephen's approach, by comparison, seems a little simpler in this respect in that each realm is there to create an particular type of "service" avatar. I still think that one realm and multiple portals is a better model but does anyone anyone else have opinions, suggestions, hints etc. Thanks, Matt -- __ / \__ Matt Goodall, Pollenation Internet Ltd \__/ \ w: http://www.pollenation.net __/ \__/ e: matt@pollenation.net / \__/ \ t: +44 (0)113 2252500 \__/ \__/ / \ Any views expressed are my own and do not necessarily \__/ reflect the views of my employer.