Hello, Diez. I know that's another option, but Chris McDonough has already explained to me why that should be avoided. This is a part of the conversation:
> > So, before implementing such a functionality with a thread-local, I > > wanted to ask: Why did you prefer passing the environ around instead of > > using a thread-local? > > The reason the Pylons folks need the StackedObjectProxy (which is a bug and > confusion magnet) is because they use thread locals like this to represent > request-local state. For instance, when one Pylons application calls into > another via WSGI, this thing stacks the environment in such a way that one > application doesn't stomp on another's thread-locals. > > SOP is nasty, and I suspect using a "bare" thread local will become > problematic in oddball environment configurations like the above, so were > it me, I'd write it in such a way that the "raw" repoze.what stuff expects > the environ to be passed in. In any case, if you do end up using thread > locals, I'd put the thread local stuff in the *calling* app, and not in > repoze.what itself. That's why I prefer repoze.what to be passed the environ every time it needs the environ. Cheers! On Monday November 24, 2008 22:57:09 Diez B. Roggisch wrote: > Gustavo Narea schrieb: > > Hello, Jorge. > > > > I think it's a good idea. > > > > However, it's better to implement it in TurboGears itself because of the > > same reason why @require has been moved from repoze.what to TG: The only > > safe way to deal with the environment is by passing it around (instead of > > storing it in a global variable, for example). > > > > If it's implemented in repoze.what, then the three functions below will > > need to be passed the WSGI environment as an argument. On the contrary, > > if they are implemented in TurboGears, they could be defined so that the > > environment isn't passed as argument. > > I don't follow that argument. It would be a very easy endeavour (and > AFAIK is already undertaken by other middlewares) to keep a thread-local > reference to the environmemnt, for such purposes. > > See the request/response variables for example. > > Now there might be other reasons not to put these functions into > repoze.what, but out of my head I don't see any. Having a > metadata-provider pluggable in repoze.who makes it worthwhile to add > convenience-functions to access that metadata. And given that repoze.who > isn't concerned with things such as groups, repoze.what appears to be > the logical place. > > Diez > > -- Gustavo Narea <http://gustavonarea.net/>. Get rid of unethical constraints! Get freedomware: http://www.getgnulinux.org/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
