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?

> 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.

(getting late - will respond more on the morrow).

Cheers,
Gary


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to