Gary Godfrey wrote: > It needs to be able to call the *right* version from deep inside the > code. You're right: wrapping is easy for the ID part. I'm making a > distinction between getting the user ID (Identity) and checking the > permissions (Authorization). Authorization can be done deep down in > the code and may require a direct call to the particular Identity > middleware. I guess I see it this way: > > Environ verison: > ID: set environ['authorization'] to ID local class (self most > likely). > Auth: call environ['authorization'].method to check. > > Library version: > Make sure identity.py is installed by any ID conforming modules. > ID: allocate new thread-safe location and put self there. > Auth: Call identity.py function which will (Given current thread > ID), lookup ID object and return with it. Call the auth method.
Errr, I'm pretty sure at this point we have significant amounts of confusion and misconceptions around this. As I'm not talking about a purely library version, its a middleware piece with functions you use in your app. The whole thing is in a single Python package. > Somehow, you're implying that there's an "identity.py" installed in > site-packages that these two different ID packages are sharing (it > could be that LDAP ID and MySQL ID are part of completely different > packages). Who installs it? Do both of them have a "identity.py" in > their install packages? I'm just saying that it's easier to share a > namespace (politically) than it is to share code. Err, no, there is a Identity site-package installed. There isn't two different ID packages sharing it, there's two differently configured ID middleware instances. > The libarary version just seems to add a whole lot of complexity. It > adds the requirement that there's a common module that is shared among > all ID providers (basically you're using the library namespace rather > than the environ namespace), it forces creation of yet another > thread-safe region (which I think does a lock under the covers), and it > just slows things down. And I'm not sure what it buys you. Either > method can be used stacked or unstacked. It buys you insane amounts of convenience, and massive boosts in usability. This is why Pylons does that, its why CherryPy does it, its why the TG WSGI branch does it, etc. Everyone's doing it cause its a "good idea" in both practice and theory. :) > I like the GlobalRegistry idea - I just don't think you can get all the > Frameworks to agree on it. I'm mostly thinking small and subversive, > here :-). BTW, to implement the globalregistry, I'd just use > environ['globalregistry']. That defeats the entire purpose of the global registry... > > I should also mention that putting things in environ doesn't solve this > > problem. Just imagine the same scenario, only you're storing your ID > > object in environ. If one of your apps down the chain uses ID as well, > > it will blow the prior ID object in environ away.... > > The question is: what's wrong with this? That's the behaviour that > you'd expect; the only time you'd want to go back up is with an > exception, and the local variables will be fine to store the ID state > for a redirect. But I can see cases where you'd want a stack. But > that's tangental to the environ/library thing. You're seeing middleware as something that just handles data on the way down. Middleware can wrap replies and alter data *on the way back up*. This is why its important not to destroy things farther down the chain. > Just curious, though: when do you ever pop? The middleware pops it. PasteDeploy comes with configuration middleware that does this, if you're curious what an implementation looks like: http://pythonpaste.org/deploy/paste/deploy/config.py.html?f=131&l=173#131 That ensures that the configuration is popped. The desire to stick everything into environ is a very common one when first getting into WSGI. There's limitations to that approach, significant ones, which is why everyone ends up using thread-locals. Typical reasons why thread-locals are a good idea: - You don't need to pass environ all over the place - No need to keep sticking more and more keys in environ when they're for use in the current space, not farther down the chain - Helper functions for templates and controllers will likely need access to configuration data. Being able to import a module global thats a request-local means your templates don't need to keep passing this data in (which saves massive repetition) Frameworks don't need to agree on the GlobalRegistry, its middleware, anyone can use it or not. The Identity middleware could use it, and no WSGI capable framework would need to be the wiser. This is why middleware is good stuff, if someone makes a more robust/reliable/fancier GlobalRegistry middleware, its pretty trivial to swap it in/out. Hopefully this helps clear some things up, otherwise I'd suggest we have a brainstorm session on IRC or something. :) - Ben --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
