In about a day I am going to present my solution by posting a patch to the appropriate drupal.org issue.

PatchRanger,

Thank you. I look forward to seeing it. By the way - I am already using the “Services” module, and “Views” module. You were mentioning some other ideas. But I wanted to let you know that I kinda already have my app communicating with these modules in this way. Hopefully you understand. Thanks!

Jay

Don't worry, the solution does fully match your requirements: check it at https://drupal.org/node/2035975#comment-7659532 .

Hello Jay,

Do you have any questions how to set up testing environment? There are quite a lot of patches included into the proposed solution and they don't look trivial though the instruction from https://drupal.org/node/2035975#comment-7659532 is quite descriptive - so in case of any difficulty I am willing to help.

Dmitry.

Hello Patchranger. I'm still testing this out. I reached a snag running the complete test install with your included make file. I'm still working on seeing what I can figure out. I don't want to just send a note such as “it doesn't work” because I hate when users do that to me! So I'm still trying to figure out what I need help on!!!

I am concerned however… I feel horrible - I should have been more specific. But we are using a different versions of the “services” module. Our software is already communicating with it and I think it would be a bear for us to change it now. I also do not know if this is a problem or not. Still testing.

The version that you are using requires a LOT of patches, etc. I think the version that I'm using is a little more stable - but also might not be as cutting edge. The last commit was a long time ago - but that tells me that it works in some ways too….

The module we are using will expose anything created by views. So all I really needed was the recurly_accounts table exposed via views. Then it would be available on our services for our other apps to use and work with. It sounds like you went above and beyond and that's great - as long as it fits with our project requirements.

Again - I'm still testing but I also wanted to get that out on the table about my concerns. Here are some links.

https://drupal.org/project/Services
https://drupal.org/project/services_views

Hello Jay, nice to hear a word from you!

I'm still testing this out. I reached a snag running the complete test install with your included make file. I'm still working on seeing what I can figure out. I don't want to just send a note such as “it doesn't work” because I hate when users do that to me! So I'm still trying to figure out what I need help on!!!

Me too: I don't like to hear such uninformative reports as 'HELP ME!!!11' :) Thanks for clarifying current situation a bit. I am still available for help. I did my best making patch instructions as clear and easy to understand as possible. Here is my additional effort: I have re-rolled the patch to make it apply automatically using drush make: https://drupal.org/node/2035975#comment-7689871 - enjoy!

I am concerned however… I feel horrible - I should have been more specific. But we are using a different versions of the “services” module. Our software is already communicating with it and I think it would be a bear for us to change it now. I also do not know if this is a problem or not. Still testing.

Please don't worry, there is absolutely nothing to be concerned about. Your existing infrastructure is not endangered or going to be replaced by that patch. As I tried to explain in https://drupal.org/node/2035975#comment-7659532 , the proposed solution is fully compatible with any software, which uses Services.
Well, let me describe it that way. The communication between any pieces of software is based on two, which are not the same:

• Client: who makes a request, asking for some resource.
• Server: who waits for requests and gives an answer.

Services module turns any Drupal site into a Server: it could begin accept requests in some specified format (JSON, XML,..) using specified protocol (REST, SOAP,..). But in order to get data from Recurly, we need to be a Client, making requests to their public API. It makes clear that services_views is not related to the task - because it can't request any data. That is what patched version of Recurly does: during execution of specially configured view (which is regular Views-plugin, you could find it among others at admin/structure/views/add) it sends a request to Recurly API and turns the response into Views output.

The module we are using will expose anything created by views. So all I really needed was the recurly_accounts table exposed via views. Then it would be available on our services for our other apps to use and work with. It sounds like you went above and beyond and that's great - as long as it fits with our project requirements.

Yes, your requirement was a lot more concrete and humble: expose recurly_accounts table to Views. I dared to re-think it and to offer you much more flexible and powerful solution.

• Could you imagine: it can get any data, available by Recurly API, and output via Views?
• It doesn't suffer from sync problems (I mean the problem of discordance: some data is at local machine, some - is inside Recurly account): everything is got directly from its source in real-time; literally “what-you-see-is-what-you-get”.
• … and other end user features, listed in the original posting.

Again - I'm still testing but I also wanted to get that out on the table about my concerns. Here are some links.
https://drupal.org/project/Services
https://drupal.org/project/services_views

Your concerns have been heard. Please continue testing - I am sure you'll be pleased with the result.
Let me remind about lifehack that I've created for you: https://drupal.org/node/2035975#comment-7689871 .

Cheers,
Dmitry (aka PatchRanger).