getSession, componentized but not async?

--===============6456829763630490702==
Content-Type: multipart/alternative; boundary=001a113f2ba00d9b2f0536e59976

--001a113f2ba00d9b2f0536e59976
Content-Type: text/plain; charset=UTF-8

I'm curious about request.getSession

Per the docs:
https://twistedmatrix.com/documents/current/web/howto/using-twistedweb.html

It seems like it's tricky to use correctly. My code needs to:
 - define an Interface
 - define a class that implements my Interface
 - call registerAdapter, passing in my class, server.Session and my
Interface
 - get a Session instance
 - brace myself
 - create an instance of my Interface class, passing in the Session instance
 - update that Interface instance.... it will persisted, but only in-memory

By default, that data doesn't go to database/memcached/whatever, so it's
only accessible in-process

On first blush, that seems like a lot of legwork. I'm not clear on what
utility's provided by all this versus say maintaining a dict as a
class-attribute on Site or something. It's also (for me) counter-intuitive
to be creating an instance of an _Interface_ and poking data into it.

Also I was a bit surprised that getSession doesn't return a deferred, since
it seems like it'd be common to want to persist session data in an external
store so that multiple twisted-web processes can access it in a
clustered/load-balanced setup. How do other folks go about that?

I hacked something together a while ago to run session data into Redis, but
what I ended up with required so much surgery on twisted web's classes that
I figured I must be doing it wrong. I think Site, SessionFactory and
Request were all customised.

I was thinking about this again in the context of Cory's "Implement
server-side HTTP/2 server push" ticket:
https://twistedmatrix.com/trac/ticket/8485

In this context, I'd like to have access to my session data in multiple
Resource objects without _necessarily_ having to round-trip to an external
store each time to get/put the same data. In the case of http 1.1 requests,
I guess there's no way around that round-trip, so it might be optimal if my
Resource objects could be oblivious to the underlying protocol version and
Session get/put mechanism.

So it'd be great if the default Session mechanism could take care of me
there, and I could just have my cake and eat it.

Another wrinkle that surprised me when I was hacking on this was that there
didn't seem to be a way to uniquely identify a request instance, so within
the session code it was impossible to tell if two calls to getSession were
coming from different points in the callback chain responding to a single
Request, or if the second belonged to a different Request entirely.

So my confusion is probably apparent at this stage :)

I'm guessing others have been here before me. What approaches have you
taken to storing your sessions? Are there good open source projects that I
should look to for best practice?

Thanks!

DJM

--001a113f2ba00d9b2f0536e59976
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m curious about request.getSession<div><br></div><di=
v>Per the docs:</div><div><a href=3D"https://twistedmatrix.com/documents/cu=
rrent/web/howto/using-twistedweb.html">https://twistedmatrix.com/documents/=
current/web/howto/using-twistedweb.html</a><br></div><div><br></div><div>It=
 seems like it&#39;s tricky to use correctly. My code needs to:</div><div>=
=C2=A0- define an Interface</div><div>=C2=A0- define a class that implement=
s my Interface</div><div>=C2=A0- call registerAdapter, passing in my class,=
 server.Session and my Interface</div><div>=C2=A0- get a Session instance</=
div><div>=C2=A0- brace myself</div><div>=C2=A0- create an instance of my In=
terface class, passing in the Session instance</div><div>=C2=A0- update tha=
t Interface instance.... it will persisted, but only in-memory</div><div><b=
r></div><div>By default, that data doesn&#39;t go to database/memcached/wha=
tever, so it&#39;s only accessible in-process</div><div><br></div><div>On f=
irst blush, that seems like a lot of legwork. I&#39;m not clear on what uti=
lity&#39;s provided by all this versus say maintaining a dict as a class-at=
tribute on Site or something. It&#39;s also (for me) counter-intuitive to b=
e creating an instance of an _Interface_ and poking data into it.</div><div=
><br></div><div>Also I was a bit surprised that getSession doesn&#39;t retu=
rn a deferred, since it seems like it&#39;d be common to want to persist se=
ssion data in an external store so that multiple twisted-web processes can =
access it in a clustered/load-balanced setup. How do other folks go about t=
hat?</div><div><br></div><div>I hacked something together a while ago to ru=
n session data into Redis, but what I ended up with required so much surger=
y on twisted web&#39;s classes that I figured I must be doing it wrong. I t=
hink Site, SessionFactory and Request were all customised.</div><div><br></=
div><div>I was thinking about this again in the context of Cory&#39;s &quot=
;Implement server-side HTTP/2 server push&quot; ticket:</div><div><a href=
=3D"https://twistedmatrix.com/trac/ticket/8485">https://twistedmatrix.com/t=
rac/ticket/8485</a></div><div><br></div><div>In this context, I&#39;d like =
to have access to my session data in multiple Resource objects without _nec=
essarily_ having to round-trip to an external store each time to get/put th=
e same data. In the case of http 1.1 requests, I guess there&#39;s no way a=
round that round-trip, so it might be optimal if my Resource objects could =
be oblivious to the underlying protocol version and Session get/put mechani=
sm.</div><div><br></div><div>So it&#39;d be great if the default Session me=
chanism could take care of me there, and I could just have my cake and eat =
it.</div><div><br></div><div>Another wrinkle that surprised me when I was h=
acking on this was that there didn&#39;t seem to be a way to uniquely ident=
ify a request instance, so within the session code it was impossible to tel=
l if two calls to getSession were coming from different points in the callb=
ack chain responding to a single Request, or if the second belonged to a di=
fferent Request entirely.</div><div><br></div><div>So my confusion is proba=
bly apparent at this stage :)</div><div><br></div><div>I&#39;m guessing oth=
ers have been here before me. What approaches have you taken to storing you=
r sessions? Are there good open source projects that I should look to for b=
est practice?</div><div><br></div><div>Thanks!</div><div><br></div><div>DJM=
</div><div><br></div><div><br></div><div><br></div></div>

--001a113f2ba00d9b2f0536e59976--


--===============6456829763630490702==
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

--===============6456829763630490702==--