Consider using ctools plugins for authentication (and maybe resources?)

@marcingy I see where you're coming from, dependence on anything can introduce overhead in syncing up and tracking the other project.

That said, while core doesn't rely on ctools, Views (in Drupal 7), Panels, Media, Features, Context, Commerce, Fieldgroup, and Entity Reference do (along with many others). Very few Drupal 7 sites will be without at least one of these modules (especially views) and most of these modules are using ctools plugins in some way. Furthermore, the ctools plugin system has been around for several years, is very stable (really hasn't changed since Drupal 6), and any API change would require updates of all of the above modules (they probably won't break stuff).

Also, it looks like the ctools plugin system is going to be a major inspiration for the new core plugin system (fingers crossed) and the ctools team is working with Crell to build said system based on the ctools model, so something that looks a lot like it will probably be in core and very standard soon(ish)™. From that post: "The Plugin Type, Plugin Implementation, and Plugin Instance are conceptually borrowed directly from ctools, and from common object-oriented patterns. It is a structure that is well-proven in the wild, both within Drupal and not."

[edited twice for grammar and punctuation immediately after posting]

One issue was I had a case for 2 authentication mechanisms from one module that tracked data common to both methods but was forced to create (at least) 1 stub module that contained nothing but the service module hooks. Also I found the interaction with the authentication plugins strange (partly because of bouncing up against #1394668: services.authentication.api.php is incorrect and #1394652: Allow multiple authentication modules to be used together).

My use case is providing one service that has 2 different authentication mechanisms. Each would authenticate on each request (my service would mostly be called to perform one operation at a time and speed was important so I wanted to cut down on the number of requests). This meant that I had to modify the method to get my auth parameters passed through and some of that stuff is poorly (and incorrectly) documented. Is there a reason this should be discouraged or is it just an uncommon case?

What I would have liked to fine (and would be willing to contribute to) is a single place where I could see exactly what the plugin defined and what interface was expected collected in one place. My inclination is to refactor service authentication providers not as modules with specific hooks and callbacks but as class based ctools plugins that implement some given interface. I think this would make all of this much more self documenting since we'll have the plugin definition info and implementation all in one place (and hopefully one interface) and we can let ctools handle all the caching, autoloading (via the registry), etc in a way consistent with a lot of contrib.

[Immediate Edit] : This would also prevent us from having the "mymodule.inc" pseudo standard for placing service methods, they'd be in the plugin relevant to the thing they're providing which (I think) makes them easier to find and if it's class based it also means you can find the relevant code via grepping because the operations are classes implementing a specific interface rather than random "whatever you decided to call them" callbacks.

Re: @kylebrowning's response in #5 I'm swamped at the moment so I won't get to it right away, but yeah I'll take a swing at a patch or gist to show what my thinking is on it (even if I don't make it fully functional before I know I have some buy in ;-) ).

re: @marcingy in #6, are you concerned about bloat in terms of code in the module itself, the amount of total code loaded or bloat in terms of conceptual overhead? In terms of service module code, I think if anything services will slim down because much of the "maintain plugin data info" structure is pushed off into ctools plugins.inc, in terms of loaded code ctools only includes the .inc files you need upon request (maybe a lil more code, but ctools plugin stuff is loaded by most requests anyway) and in terms of conceptual overhead, I think this will make services easier to think about and talk about and more in line with the other systems I listed in #2.