Has anyone done work on this and can offer any learnings/gotchas?

I need to handle multiple "session" containers each request object.  One of 
our products is a platform with whitelabel functionality, so a request can 
happen on the platform domain OR a partner domain, and can be stored 
clientside or serverside:

* platform domain - serverside container (https only)
* platform domain - clientside container (http+https)
* partner domain - clientside container (http+https)

The current approach works, but is not nice to maintain or grow. We have a 
new ISessionFactory subclass ISessionHTTPSFactory which is registered to 
`request.session_https`.  A custom session factory is then used to handle 
the right http/https backend stores, and some request methods are used to 
streamline accessing them.

What I'd like to move towards, is dropping the ISessionHTTPSFactory subclass, 
and either use only `config.set_request_property` and/or having the  
ISessionFactory 
subclasses automatically created/managed as needed.  The goal is to not 
require creating/managing these subclasses and their mountpoints hardcoded, 
but allow them to be easily changed.  I need to add two more clientside 
"sessions" for https connections to our platform, and the current method 
won't scale like that.  

These are all true "sessions" and leveraging pyramid ISession libraries but 
the data has different retention needs and usage policies.  we often split 
things into multiple apps, so a few might have access to every payload but 
others can only access one payload.

If anyone has done work, or even thought on this, i'd be grateful to know 
any tips or missteps.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/1cc768d9-dabc-4b86-8ce9-d7dc7fe5f544%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to