Doing research into the best way to create a central OpenID server to power logins across BlurryWorks.
I first attempted to hit the ground running with merb, but immediately fell over myself due to complexity and lack of documentation. Not that merb is incredibly complex, but rather that searching through RDoc trying to string together the pieces I needed to port the OpenID-Enabled libraries from the Rails example to merb was causing me a bit of grief. I then went the rails route which I was more familiar with, and using the example, setup a implementation that provided the Rely server model I needed.
I’m not terribly happy with this approach as Rails is just a tad bit much for a rather simple application. All the application needs to do, is field incoming users, ask for their openid url, kick off the crypto and session for that request and send the user off to their provider, then when they come back, either report their error, or establish a BlurryWorks based session. Other BlurryWorks sites and applications will refer back to this login system to determine a User’s identity via cookies.
Later on I intend to expand the system to act as a provider, and provide tools for users who have logged into the system.
While this is a relatively robust requirements, it doesn’t need the tools provided by Rails. Thus I am currently looking at writing the application entirely inside Rack or going up one level and writing on top of Thin.
Python is included in the list of stuff I was looking at, more as a cursory interest rather then an intended shift. I occasionally dabble in Python as a tool set for building, administrative, and (server) operations needs, but don’t yet see a need to leave ruby for. It is interesting to see the current state of python webframeworks though, and that Rack was built off the model from Python Pep 333.