Re: OpenID in PEAR

Hey Paddy... Pádraic Brady wrote:

First up, I'm unsure of class name. OpenID 2.0 is geared up for authentication (Auth!) but allows for Server querying, and intra-Server data exchange (Services!) and doesn't enforce any external data storage/method of operation. The services element isn't essential, so I've written code just from a base "OpenID" classname, rather than "Auth_OpenID" (still categorised under "Authentication"). Not sure if this works, is permissable, or should be put elsewhere.

In playing with JanRain's code, it seems like OpenID consumer code functions as a web service. Maybe that's the place for it to exist. The server component is also a web service of sorts, but on a different level. There do appear to be a few server related packages in the web services category, so that might work. With that, you could wrap an simple authorization adapter around Services_OpenID to hide some of the complexity with a simple true false return while not cheating someone out of the entire OpenID spec if they need it.

Secondly, the proposals (OpenID Consumer, OpenID Server) are not two distinct packages as such. Since both the Consumer and Server likely depend on and share code (notwithstanding the already extracted Crypt/Yadis packages) they are located in the same source tree. So, for example, OpenID_Consumer and OpenID_Server both utilise OpenID_Nonce - there's no other class depth, i.e. no OpenID_Consumer_Nonce and OpenID_Server_Nonce. So, both proposals would refer to the same source code tree. The reason for two proposals, is mainly to split up the review process. I'd much prefer to get the Consumer reviewed, and then integrate the Server after all comments have been accounted for. The Consumer

How about this structure: * Services_OpenID * Services_OpenID_Common * Services_OpenID_Server The base package serves as the consumer code with the other two being obvious. Services_OpenID could be bundled with Services_OpenID_Common, but Services_OpenID_Common can be installed without Servicse_OpenID. That allows someone to install just Services_OpenID_Common and Services_OpenID_Server without the need for the consumer code if all they are doing is a server. Besides, I need a guinea pig to test my phing task's bundling functionality on once I implement it... ;-)

This is about 95% of the necessary code for an OpenID Consumer - the other 5% is why it's incomplete and may fail the moment you stray from the beaten track. I guess the funny thing with specifications is that it's always the last 5% of code that makes it work - the rest is all useless until then.

How true... Try implementing a JCR spec sometime. "Is this ever going to do /anything/?" :-) -Travis