On Jul 7, 2016, at 7:50 AM, Donal McMullan <donal.mcmullan@gmail.com> wrote:

This can actually be useful in larger systems where you are making use of heavily componentized code, but in some cases it does seem like overkill.

That's close to the heart of the question. In larger systems, what is useful about the componentized session objects in particular (as opposed to components/adapters/interfaces in general)? It's a very particular API, so I guess there's a reason for that.

The issue is that larger systems may be integrating several components, each of which may have its own requirements of session data.  Each stipulates those requirements in terms of an interface, and then the session is a mapping of {interface_describing_required_behavior: application_specific_behavior}.

The reason this works better in "larger" systems is that if you have only a single codebase with only a single set of requirements on its session, you'll only ever need a single key in that mapping, and a single interface.

As for persisting session data-- I guess the idea is that storing or retrieving the session object doesn't need to be async because it is just an object in memory corresponding to a cookie in the request.

But doesn't that mean it's impossible to restart the process without destroying user session data? That doesn't seem ok. Isn't that a problem for your cas proxy?

No; the idea is that you have an object in the session with Deferred-returning methods to retrieve data from your data store.  What the session store is doing synchronously is simply converting the cookie data into a token that can be used to access a back-end; the actual data lives in the back-end.

-glyph

_______________________________________________
Twisted-web mailing list
Twisted-web@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web