[Twisted-Python] usage of sessions in twisted.web?

[Glyph Lefkowitz]

On Sat, 21 Dec 2002 12:26:04 -0500, Steve Waterbury <waterbug at beeblebrox.gsfc.nasa.gov> wrote:
> We are not using sessions yet, but plan to in the near future.  

Good... the "near future" will be a good time to start :-)

> Currently we are using the twisted xmlrpc for communication to our GUI client
> (developed using wxPython), but we also plan to have a browser interface
> (almost certainly using Woven), a SOAP interface, and quite possibly others
> (e.g., PB and/or CORBA).

Wow!  Did Twisted inspire you to use such a diverse assortment of frontends, or
was it part of your charter and why you chose it in the first place? :)

> Do you plan to make your new Sessions implementation general enough to
> support all of these?

This is a hard question to answer as asked, so I'll take this opportunity to
lay out my vision for how multi-protocol "sessions" are supposed to work.

There are two answers: yes, I plan to make Session part of a system general
enough to support all of these front-ends.  Also: no, I do not plan to make
Session general enough to support all these itself :-).  If you've been a good
disciple of the Twisted Way, you'll have a Service with Perspectives that
represent the way that users interact with your system.  That's the focal point
of the conversations your users will have with your abstractions.  Web session
management is a mostly-separate system, more of a kludge over the HTTP protocol
than a general way of representing stateful interaction.  The cool thing about
the new web session wrapper (now checked into CVS in twisted.web.woven.guard)
is the fact that it can negotiate with the browser to discover whether cookies
are turned on, more or less automatically, and provide effectively the same
experience whether they are or not.

I'm still working on the web part of the cross-protocol part of this system.
In twisted.cred, there are 4 real abstractions documented so far: identity,
perspective, service, authorizer.  There is a 5th though, which has really only
been used by PB so far: the notion of a "client object".  (That's a terrible
name, I know, but it seems to describe its function.)

Abstractly, the client object is representative of the "other side" of some
connection to the user.  In PB, it's usually a RemoteReference that the client
sends as part of the authentication sequence, so the service's side of the
interface to this object will often be through callRemote.  (There are no
restrictions on what kind of object it is, though, so your service is welcome
to do whatever is appropriate.)

In the case of something like IRC, the "client" will simply be an instance
wrapping the IRC Protocol instance.  For the web, it will be an object stuck to
your Session (which has been initialized using the handshake code above).  In
the PB case, it's an instance of an object on the other side of the Broker, as
I said above.

Once you've decided what kind of client object you're using, however, the
'attached' method of your perspective will be called with it.  When you log out
/ your broker goes stale / your IRC connection drops / your web session times
out, the symmetric "detached" method is called.

I hope that this explains what how should be expecting to use the
authentication part of the new twisted.web.woven.guard once it's finished, but
feel free to ask for clarification.  I really can't think of how to express
this well :-).

> (Given your usual sound architectural principles, I would expect so, but you
> might have practical reasons to make it more specific, so just thought I'd
> ask. :^)

-YES-.  MY DESIGN-FU IS STRONG RARARA

-- 
 |    <`'>    |  Glyph Lefkowitz: Traveling Sorcerer   |
 |   < _/ >   |  Lead Developer,  the Twisted project  |
 |  < ___/ >  |      http://www.twistedmatrix.com      |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/twisted-python/attachments/20021221/9d379ced/attachment.sig>