On Wed, Jul 7, 2010 at 10:31 AM, Marius Scurtescu <[email protected]> wrote: > On Wed, Jul 7, 2010 at 1:10 AM, Michael D Adams <[email protected]> wrote: >> Actually, for a small minority of WordPress sites wanting to enable >> OAuth (those not supporting so called "pretty permalinks"), the >> WordPress plugin would need to internally reserve one query parameter >> to get the ball rolling. Theoretically, that need leads to the >> possibility of conflict, but I'm not worried about it. > > As far as I can tell pretty permalinks also use mod_rewrite so the PHP > code still sees the query parameter.
Yes. The point is that the plugin can intercept the request early enough that it doesn't matter. There is a small chance for conflict, but the conflict is not inherent to the core spec or to the spec of an extension, only to the particular implementation of the plugin. In the pretty permalink case, the conflict can easily be addressed with a new release of the plugin (developed, out the door, and pulled to all sites in a day) without changing endpoints or otherwise breaking clients. In the ugly link case, you might need to change the endpoints' URLs. Any "serious" site will be using pretty permalinks. This situation seems acceptable to me. With a new extension, you need a new release of the plugin anyway (or the release of a plugin for the plugin). You're blocking deployment on development, which is always true. All of this to say: WordPress is flexible enough to implement the current spec, and I predict that WordPress is flexible enough to implement the final spec. I believe no special consideration need be given WordPress in the spec writing process. If I see anything, I'll raise the issue. Mike --mdawaffe _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
