OpenID Libraries should be stateless

[Kevin Turner]

On Tue, 2008-02-05 at 12:00 -0800, Ryan Ernst wrote:
> I understand it is the same amount of work, and I'm happy to do it,
> but I don't want to do it (assuming certain internals of the library)
> and then have to check with each new release of the library that my
> code hasn't been broken.  

We do make an effort to preserve API compatibility between releases.
It's true that, the farther you get away from consumer.Consumer and in
to the internals of the code, the more cavalier we are about that -- I
think Python interfaces are particularly prone to public/private
interface confusion -- but parts that people have told us they need to
use can be treated as public.  If we break those, we'll make a note of
it in the NEWS file.

> I have no problem storing the state into a dictionary as it is now,
> but I would like to pass the values of that map as get parameters,
> signed.  Once I have more than one application server, I can't do that
> (the object references won't make sense anymore).  

Hmm?  It's pretty common for python servers to dispatch requests to
various different fastcgi or mod_python processes, and I think if object
references between different processes were a problem, we'd know it by
now.  It's entirely feasible to marshall that entire structure and read
it back in to another process.  Pickle handles this just fine.

A word of caution:  One reason we abandoned the "stick everything in a
GET parameter" approach was that OpenID GET requests can be rather large
(especially if you start making use of extensions), and there is an
upper limit on the size of a GET request, and while *most* sets of
discovery information that will be cached are small, a user _may_ have a
very large set of OpenID endpoints.  You can dance around this to some
extent by using POST with OpenID 2, but things may get slow and messy.