On Nov 4, 11:11 pm, Gustavo Narea <[EMAIL PROTECTED]> wrote:
> 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.
It is some respects hard to explain what am talking about without a
reference implementation, but this isn't about adding in actual code,
but more about setting the interfaces and how different parts of the
authentication, session management, session database components
communicate.
Thus is it a generic specification on top of and adjunct to WSGI
specification, not a lump of code which binds you to Apache. The
intent being that it would be a generic mechanism for passing data
which can equally be used by other WSGI components for providing the
functionality.
Anyway, looks like it will have to be a battle for another day.
Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
