On 3/5/06, Gary Godfrey <[EMAIL PROTECTED]> wrote: > > Ben Bangert wrote: > > Again, is there some reason that won't work as a function? Heck, its > > just a function you put in the environ, isn't it? That already means > > you can use it as a library. Why does sticking the function in a dict > > thats passed around make it any more framework-portable than a library? > > Maybe I'm not quite understanding something here. Let's suppose I > have a wsgi stack like (apologies if diagram doesn't make it through): > > == SERVER == > = Virtual Host Splitter = > > = ldap ID = mysql ID = > = TG Blog = TG Blog = > > OK, so we have two different web sites hosted virtually on a single > WSGI Server. The TG blog code needs to call either the LDAP ID > mechanism or the mysql ID mechinism depending on which path was taken. > So, the "import Identity" used inside TG Blog needs to mean different > things depending which one is called. How would that work?
If the WSGI manager can activate a different middleware stack depending on the URL, there would be no interference. I don't remember if Paste can do this. If there's one global middleware stack, and if the config file can handle host-specific configurations the way it does path-specific configurations now, you'd have two options: 1) Use a robust middleware that can handle multiple backends and switch per request. Put the connection info in the config file for each host. The middleware may want to use a connection pool bla bla bla. 2) Use two stupid middlewares that can be disabled in the configuration. Activate one for one host, and the other for the other host. This is similar to Apache's "LoadModule" and "ModAuth Off". The middleware is running but will pass the request/response unchanged if disabled. Of course, if there's no interaction between the sites, and they're on different IPs or ports, there's no need to multiplex them in one process at all. > > Sure, though environ is thread-safe mainly because its a dict. > > Cluttering environ is no better than cluttering the namespace, but > > thread-safe module globals are a good way for some things to function. > > See, "thread-safe module globals" always scare me. Every time you have > to look up the current thread and map that to the right thread-safe > value is a potential for screwing things up. That should only be done > rarely, ideally not by everyone who implements a feature. That's already been done. 'cherrypy.thread_data' is a dumping ground for any per-thread objects you need. 'cherrypy.request' is also local to the thread, so 'cherrypy.request.wsgi_environ' would be too. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
