Hello, On Tuesday November 4, 2008 12:52:15 Graham Dumpleton wrote: > But doing it exclusively at the WSGI level is the problem and is > actually limiting Python web applications from being able to use > features already provided by web servers.
I think that's a decision that should be made by the TG application developer, not by us. I think we may provide a sort of plugin that interacts with that Apache- specific feature, but not put it in the TG core. > Having it done within a specific WSGI application instance means you > cannot readily do single sign in across distinct applications, whether > they be Python WSGI, PHP or something else, hosted at the same time in > a server such as Apache. The idea that one would somehow composite the > distinct WSGI applications together within the one process or sub > interpreter context will not work, as various Python WSGI applications > will not play nicely together or you can't have multiple instances > running together. You therefore often have no choice but to run them > in separate processes and at that point you need to be able to > delegate the single sign in to a higher level. Delegation to higher > level is also needed to bridge single sign on easily to web > applications in other languages. I like the goal, but not implementing a functionality specific to one webserver in TG. I think this would deserve its own TG extension or its own independent project so that it may be used by any WSGI application. > I am also not suggesting that one be tying one self to Apache. When > one delves into how mod_session works, one will find that what it does > is no different to how a WSGI middleware can provide a service to a > nested WSGI application through passing information through the WSGI > environment dictionary and then getting back information via response > headers. What I suggesting is a standardisation on how that is done > which would so happen to work with mod_session, but which would also > work for WSGI middleware components providing the same sort of > functionality. That is session abilities could be provided by Python > WSGI component within standalone WSGI application, or because the > method of interaction is the same, delegated back up to Apache instead > so that single sign on across applications can be more easily > achieved. The intent being here that lower level application > components running within it would know or care whether sessions being > handled by Apache or by a Python based WSGI middleware component. I see, then I think it's better not to have it in the core. Let's see what others think. Cheers! -- 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 -~----------~----~----~----~------~----~------~--~---
