Port to drupal 7

APIs for Drupal 7 aren't fixed yet. So starting on even porting work won't be worth it until the D7 features are fixed in September.

I emphatically agree that it's far better to port modules to D7 during code thaw while we can still do something about it if the APIs need work.

Note that Drupal 7 has hook_page_alter() which the services module might be able to use in order to dynamically change the type of output that comes out. You might want to speak with Moshe or Peter Wolanin on IRC, as I think they had some sort of plans about putting a dynamic switcher to output XML/JSON/SOAP/etc. Maybe if we include that part of Services in core, this becomes a much easier issue to tackle. ;)

Hi marcingy,

What's the status on Services into Core?

Porting to D7 was not difficult.

May you give me CVS access please?

Thank you,
Nick

OK, but how is the status? Is it going to core?

Oh, ok. Is it possible for me to have CVS access? Do you have contact with the maintainer? I prefer it over creating patches. Thanks!

I'd like to go on record against any attempts towards Services in core for D7. It is very late, and any attempts to shoehorn it in before code freeze feel like they would be fraught with danger. I'm also, personally, not sure it belongs in core at all. #smallcore is calling my name. Lets wait for D8 and see where things go.

Hi Marc,

Has Nelson positioned himself over this issue? It has been about a week since I've sent him that email with copies to you and Rob.

Thanks,
Nick

Marc and I had a quick talk about this and there might be a place here where we could take advantage of the #theme_wrapper of the new render system. Haven't done too much research, but it might be worth investigation.

I'm attaching a services "lite" version that works with the current Drupal 7 code freeze. By lite I mean that I've stripped down all the confusing authentication settings available. I didn't include the available services as they have been in an incomplete state for a long time. If anyone really needs them, it's not hard to borrow some code from Bruno at (http://drupal.org/project/webservices). Instead of having the XMLRPC server code, I included the JSON server code (http://drupal.org/project/json_server), which is a far better option to work with in this modern Web age. I've updated it to the current Drupal 7 code and created support for POST/GET and JSONP. If anyone needs any help, feel free to drop me a line! Kind regards, Nick

You're welcome. BTW, # 6 is still available and has been updated.

Initial patch to port Services to D7, along with some tag updates to get more involvement. I've hit all the high points in the d6-d7 conversion page for the main service module, along with a few mods for the services_keyauth. There's some issues in the install of services_keyauth that need some tweaking. Patch applies to 6.x-2.x-dev.

Marcingy, was the patch rolled for 6.x-2.x or shall we go for HEAD on the 7.x port?

Just to mention, I'll join into this issue queue to help as much as I could. I commented yesterday to marcingy on IRC that I've started to write some simpletest cases, but I guess all the effort should be moved into this branch instead of 6.x-2.x (I started on that branch).

Patch applies succesfully, and ahah problem is gone with the patch at #21. I'll start moving current testcase for D7.

Found this:

- in function services_form_alter, the form_id to attach the cache clean function is not 'system_modules' (this is the D6 form name) and should be 'system_performance_settings'.

Have not reviewed the cache functionality yet.

Some additional abstract thinking and discussion on how Services could improve in Drupal 7 is in #610698: Refactor the Services module.

I totally agree, a better approach could be get once we are working on a real D7 version.. marcingy, for this, heyrocker and I agreed in having a project branch (we may use HEAD or a new DRUPAL-7--1 to start submitting issues properly, and also have completely separated tasks from current 6.x-2.x branch.

If there is consensus, it worths to create that branch and put this patch applied in it. It's a very big path, hard to completely review and useless unless you apply. Nodoby but us will use that D7 branch, so if you apply the patch, and commit the changes to that branch, we can start creating issues while we are reviewing, making transaction easier.

----

Still reviewing (having in mind removing the browser testing interface for a smaller module #1)..

- http://host/?q=crossdomain.xml returns Fatal error: Call to undefined function services_get_keys() in ..services\services.module on line 147
There is a hidden dependency here, because it's using a function from services_keyauth

- I guess, we should work more on keyauth splitting.. E.g: in hook_help at services.module, we have: case 'admin/build/services/keys', this should be moved to services_keyauth module.

- hook_theme in services is used for the browser testing interface.. can be remove now that this interface will be splitted from the D7 version?

- services_auth_invoke could be reduced as:

  services_auth_invoke ($method, &$arg1 = NULL, &$arg2 = NULL, &$arg3 = NULL) {
    $module = variable_get('services_auth_module', '');
    return services_auth_invoke_custom($module, $method, &$arg1, &$arg2, &$arg3);  
  }
 

- and services_auth_invoke_custom may return an error when no authentication module is enabled (instead of current TRUE):
return services_error(t('Unathorized by service provider'), 403); (edited)

- in services_method_call: authentication should be checked before method and arguments.

- resource helper functions should go into a separate file to be used with modules providing resource services?

- if authentication is required to access services, and services_keyauth is another module, could we get the session configuration code back from services_keyauth into services.module.. being services responsible of managing the session based authentication?

----

No more for now. I've only reviewed the services.module file.. I'm including some tests for the crossdomain.xml and some basic interface checks for services module. I'll try to pack all the basic tests and submit for review, maybe into that 7.x-1.x-dev branch? ;)

Cheers,
ilo

Thanks marcingy :)

I'll be submitting patches also, so I guess we should start converting all this stuff into real issues, and have some work paralelized.

Reviewing the services.install file, some elements should be moved to services_keyauth.install (deleting variables, etc..) .

As it will be a new 7.x-dev package for a while, not having any previous release, I wonder if we should keep all these updates affecting the key schema or just provide a 6.x to 7.x unique upgrade, keeping key upgrades in services_keyauth.install file.

I'm not sure how this upgrade path should work either. We will definitely want to provide a unique upgrade path, but I don't know the best way to make that work and split it out as well.

I don't know a good place to surface it (maybe we need a task list of some sort) but we should definitely expose some blocks for the new admin dashboard. Bring the sexy, it'll be cool.

I agree with heyrocker about a task list. Probably I'm not the right person to provide with this kind of ideas, as I'm not aware what is the final idea of the services module. I'm building this list from my understanding of the issue queue:

- Remove authentication dependencies:
- finish the Splitting of services and services_keyauth completely
- services.module to handle session authentication

- Refactor services module helper functions:
- split resource helpers and include them only in resource services (_service module).
- Remove service browsing: and split into a browser_server implementation, creating the UI suggested by Marcingy. As long as we have simpletest, the browser functionality in services is not required to do manual testing.
- Resolve Crossdomain.xml issues: other modules require this file (e.g. kaltura and piclens > 600 usages), and now it's kidnapped by the services module.

Other ideas..

- Implement services _alter hook: allowing other modules to alter services definition.
- refactor session based authorization: permissions to use services with/withouth the session
- services_keyauth authorization, no longer authenticates: using the services _alter hook, this module can introduce API key field in required services.
- Implement blog api service module..

Just to have something to start with..

I've had the opportunity to talk with heyrocker these days, and now is quite clear for me what the upgrade process could be. I would love to see a list of module assignment, just to avoid submitting two times the same patch, I'll be upgrading 6.x-2.x sub modules to D7 also this weekend.

I'll get the taxonomy_services module, because of my previous experience on new taxonomy for D7, it is quite hard. The rest we can just assign whatever we want to. Does it worth to keep an issue for each sub module to be upgraded to D7? This way we can see the assignment and work on other files.

C'mon Marcingy, or you'll loose the best part of the party :)

> Yes we all want D7 services to funky, cool etc
No. Foremost we want it to be simple. Just follow the KISS philosophy:
http://drupal.org/node/624906

I agree with ilo on several issues he mentioned here about how the authentication process is complex:
http://drupal.org/node/610698

Plus, this CRUD-awareness is unnecessary and too complicated IMHO. How did that got in so easily?
http://drupal.org/node/466922

@nickvidal so far nobody but you has proposed a vastly stripped down version of services, so i don't know how you can say "we" want it to be simple. I am sure that some may agree with your proposed changes and some may not, however the only way this can be worked out is through small steps, gradual change, and patches. If you do not want to deal with submitting patches to the queue for review, then that is your business. However this is how it will happen.

If I'm the only one, then how can you explain the fork:

http://drupal.org/node/305523

Just about every issue is due to the complexity of this module:

http://drupal.org/project/issues/services

Have you even bothered to take a look at the code:

http://drupal.org/node/477012#comment-2050614

The fork came because of the same reason yours will come (I assume) - Bruno was unwilling to work with the team, together as a team. He committed code to CVS without discussing it with maintainers, he made API changes to an existing branch of code without telling anyone. Bruno's removal from the Services team had nothing to do with the technical merits of his contributions, but because of his inability to play well with others. Even after that he could have continued to submit patches for discussion with the team, but he did not, he chose to fork.

Submitting patches, discussion with people, slow steady change in the issue queue to build up trust. This is how Drupal works. Sometimes you will make arguments and lose too, that doesn't mean people are "hard to work with", it just means you couldn't convince anyone. This happens. Get used to it.

I'm trying to discuss and play well. Could we discuss it over here please:

http://drupal.org/node/624906

Thanks,
Nick

Closing this issue as it's no longer relevant for the 7.x port.