>
> No; the idea is that you have an object in the session with
> Deferred-returning methods to retrieve data from your data store.
Ahhhh - Carl was trying to explain that. Sorry guys. I get it finally.
The issue is that larger systems may be integrating several components,
> each of which may have its own requirements of session data.
Hmm.
Thanks glyph
DJM
On 7 July 2016 at 23:24, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote:
>
> On Jul 7, 2016, at 7:50 AM, Donal McMullan <donal.mcmul...@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
>
>
_______________________________________________
Twisted-web mailing list
Twisted-web@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
