Re: getSession, componentized but not async?
Glyph Lefkowitz <[email protected]> Thu, 7 Jul 2016 15:24:34 -0700
| Newsgroups | gmane.comp.python.twisted.web |
|---|---|
| Message-ID | <[email protected]> |
--===============1049081687187121206== Content-Type: multipart/alternative; boundary="Apple-Mail=_5689B15B-540D-4FAF-AA35-6EBB74FEE0A1" --Apple-Mail=_5689B15B-540D-4FAF-AA35-6EBB74FEE0A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 7, 2016, at 7:50 AM, Donal McMullan <[email protected]> = wrote: >=20 > 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. >=20 > 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 --Apple-Mail=_5689B15B-540D-4FAF-AA35-6EBB74FEE0A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On Jul 7, 2016, at 7:50 AM, Donal McMullan <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(= 204,204,204);padding-left:1ex"><span style=3D"font-size:12.8px" = class=3D"">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.</span></blockquote><div class=3D""><span = style=3D"font-size:12.8px" class=3D"">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.</span></div></div></div></blockquote><div><br = class=3D""></div><div>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}.</div><div><br class=3D""></div><div>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.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px = 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(= 204,204,204);padding-left:1ex">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.</blockquote><div class=3D""><br = class=3D""></div><div class=3D"">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?</div></div></div></blockquote><br class=3D""></div><div>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.</div><div><br class=3D""></div><div>-glyph</div><br = class=3D""></body></html>= --Apple-Mail=_5689B15B-540D-4FAF-AA35-6EBB74FEE0A1-- --===============1049081687187121206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web --===============1049081687187121206==--