Re: getSession, componentized but not async?
Donal McMullan <[email protected]> Fri, 8 Jul 2016 03:54:35 +0100
| Newsgroups | gmane.comp.python.twisted.web |
|---|---|
| Message-ID | <CADf-aJG_ka=q0tUJM7F-L974idO2uc_TzWvFdLxdOiWip-zypw@mail.gmail.com> |
--===============4997920870136619473== Content-Type: multipart/alternative; boundary=001a114be688461c64053716ec54 --001a114be688461c64053716ec54 Content-Type: text/plain; charset=UTF-8 > > 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 <[email protected]> wrote: > > On Jul 7, 2016, at 7:50 AM, Donal McMullan <[email protected]> > 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 > [email protected] > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web > > --001a114be688461c64053716ec54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r= gb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.8px">No; the = idea is that you have an object in the session with Deferred-returning meth= ods to retrieve data from your data store.=C2=A0</span></blockquote><div><s= pan style=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-si= ze:12.8px">Ahhhh - Carl was trying to explain that. Sorry guys. I get it fi= nally.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex"><span style=3D"font-size:12.8px">The issue is that larger s= ystems may be integrating several components, each of which may have its ow= n requirements of session data.=C2=A0</span></blockquote><div><span style= =3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px= ">Hmm.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><= div><span style=3D"font-size:12.8px">Thanks glyph</span></div><div><span st= yle=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.= 8px">DJM</span></div><div><span style=3D"font-size:12.8px"><br></span></div= ></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 7 July = 2016 at 23:24, Glyph Lefkowitz <span dir=3D"ltr"><<a href=3D"mailto:glyp= [email protected]" target=3D"_blank">[email protected]</a>></spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-w= ord"><br><div><span class=3D""><blockquote type=3D"cite"><div>On Jul 7, 201= 6, at 7:50 AM, Donal McMullan <<a href=3D"mailto:[email protected]= m" target=3D"_blank">[email protected]</a>> wrote:</div><br><div>= <div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r= gb(204,204,204);padding-left:1ex"><span style=3D"font-size:12.8px">This can= actually be useful in larger systems where you are making use of heavily c= omponentized code, but in some cases it does seem like overkill.</span></bl= ockquote><div><span style=3D"font-size:12.8px">That's close to the hear= t of the question. In larger systems, what is useful about the componentize= d session objects in particular (as opposed to components/adapters/interfac= es in general)? It's a very particular API, so I guess there's a re= ason for that.</span></div></div></div></blockquote><div><br></div></span><= div>The issue is that larger systems may be integrating several components,= each of which may have its own requirements of session data.=C2=A0 Each st= ipulates those requirements in terms of an interface, and then the session = is a mapping of {interface_describing_required_behavior: application_specif= ic_behavior}.</div><div><br></div><div>The reason this works better in &quo= t;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 s= ingle key in that mapping, and a single interface.</div><span class=3D""><b= r><blockquote type=3D"cite"><div><div dir=3D"ltr"><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef= t-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">As for p= ersisting 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 i= n memory corresponding to a cookie in the request.</blockquote><div><br></d= iv><div>But doesn't that mean it's impossible to restart the proces= s without destroying user session data? That doesn't seem ok. Isn't= that a problem for your cas proxy?</div></div></div></blockquote><br></spa= n></div><div>No; the idea is that you have an object in the session with De= ferred-returning methods to retrieve data from your data store.=C2=A0 What = the session store is doing synchronously is simply converting the cookie da= ta into a token that can be used to access a back-end; the actual data live= s in the back-end.</div><span class=3D"HOEnZb"><font color=3D"#888888"><div= ><br></div><div>-glyph</div><br></font></span></div><br>___________________= ____________________________<br> Twisted-web mailing list<br> <a href=3D"mailto:[email protected]">Twisted-web@twistedmatrix.= com</a><br> <a href=3D"http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web" r= el=3D"noreferrer" target=3D"_blank">http://twistedmatrix.com/cgi-bin/mailma= n/listinfo/twisted-web</a><br> <br></blockquote></div><br></div> --001a114be688461c64053716ec54-- --===============4997920870136619473== 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 --===============4997920870136619473==--