wpopenid-architecture-brainstorming

From DiSo wiki

The trick to expanding wp-openid heavily is to make sure it's done in a way that is scalable and extensible. The more we talk about adding functionality, the more it seems like the current architecture of the plugin doesn't necessarily lend itself to what we want and may need to be redesigned. It was certainly not designed for this, and that's okay... we just need to be careful not to try and build a skyscraper on a foundation intended for a one story home.

Overall Design

I know we've *talked* about it this way, but we really need to change wp-openid into an Engine that allows other functionality to plug into it. The engine should support allowing plugins to...

• register endpoints that will receive requests. Any request at these endpoints should be passed off to the plugin
• register XRDS data that is displayed on Accept: application/xrds+xml requests (perhaps build on Stephen Weber's work)
• hook into any additional events. We'd use wordpress's existing hook and filter infrastructure, but add in a few hooks of our own

Given this architecture, even the openid consumer functionality that currently exists in the plugin should probably be a plugin to the engine. Similarly, wp-yadis would be a plugin that just registers XRDS data. OpenID Provider functionality would be provided as yet another plugin. To avoid confusion, a number of the most common plugins would ship with the core engine (still advertised as "wp-openid").