Derived from #1033818: Move xmlrpc includes into xmlrpc.module, this issue is to track the removal of the XML-RPC API in Drupal 8.0

Milestones to remove something from core should include:

  • at least a basic review of how much the code is used in core and the broader world of contrib
  • at least the start of a migration path to a contrib module and someone who will maintain that (I assume fgm is at least as willing to do that as he was core?)
  • agreement from core committers
  • agreement from the person responsible in MAINTAINERS.txt
  • a patch that passes tests

In no particular order:

  • Since there is no Blog API in Drupal core anymore, there is nothing left in core that actually makes use of the XML-RPC library, meaning there's no reason to have it left in core.
  • XML-RPC is used less and less by contributed modules or newly built sites. Instead people use RESTws or Services or other more modern styles of APIs.
  • kim.pepper created a sandbox with history #1285726-38: Remove XML-RPC (though its been pointed out that full history will always be in the core repository)
  • xmlrpc maintainer fgm is not as opposed as he once was and basically agrees to removing it: "So let's go with the times and be done with it" #1285726-33: Remove XML-RPC
  • Core commiter Alexpott is "+1" to removing it #1285726-32: Remove XML-RPC
  • Core committer Catch is +1 to removing it #1285726-39: Remove XML-RPC
  • Web Services Initiative Lead Crell is +1 to removing it
  • There is still a lot of work to do to make xmlrpc match the code style/architecture of D8.0 #1285726-22: Remove XML-RPC. Removing it now should help to get D8.0 released sooner.

Next steps:

A commit.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fgm’s picture

I generally disagree with the reasoning leading to this removal, but since we are going to build a completely different approach with WSCCI anyway, it can reasonably be done, as long as some form of XML-RPC itself remains in core.

Now, why do I disagree with raw removal:

a) this is one more core feature which defined Drupal and was one of the two key reasons why I chose it over alternatives initially in 2005 (the other being taxonomy). If we follow the heuristics thread for core selection or the monster removal issue, the builtin XML-RPC server doesn't match the removal score
b) XML-RPC is the simplest program-to-program mechanism available for web apps, with less limitations than REST applications, less overhead than SOAP, and better sheer doability in user space than DCE or NCS.
c) On a more personal note, it is a major building block in /all/ large sites and most medium-sized ones I've been working on since 2005, which is why I worked on it in core since the changes in D4.7.4. But of course, this needn't be a criterium.
d) There is no issue regarding maintenance of this specific core part: we evolved it significantly for D7, and I am quite willing to continue maintaining it in whatever form it will take in core D8.

sun’s picture

Status: Needs review » Postponed

@fgm: Thanks for your subsystem maintainer perspective!

The reasons for postponing this are:

  1. It should be a cleanly separated module first, which is able to work on its own. (the other issue)
  2. There should be a direct equivalent subsystem/functionality in core that allows a Drupal site to expose itself as a web service. (likely/hopefully result of WSCCI, but frankly, I don't really see a sign of progress on that yet)
  3. This case should be passed through our fresh and cool attempt of "core heuristics" to get a better understanding first.
RobLoach’s picture

I completely agree we need to segregate this into its own module over at #1033818: Move xmlrpc includes into xmlrpc.module before considering its move to contrib. In the mean time, here are my thoughts on #1273344: Establish heuristics for core feature evaluation:

Is it needed for Drupal web sites, automated tests, installation profiles, or drush commands to operate properly?
No.
Is it a "defining" quality of Drupal or an important differentiator from other web CMS projects?
No.
Is it a "building block" that can be used to implement many different user-facing features?
User-facing? Not really.
Can it be controlled or managed from a variety of tools (drush, GUI admin tools, install profiles, packaged configuration, etc.)
No.
Would it be impractical or impossible to implement as an optional plugin or contrib module?
Not at all: http://drupal.org/sandbox/robloach/1285602 . We have to put together a patch which moves it to a module at #1033818: Move xmlrpc includes into xmlrpc.module.
If more robust solutions to the same problem exist in contrib, is it compatible with or "easily migratable to" the contrib solution?
Easy to migrate to http://drupal.org/project/services ... We are missing Blog API though, since that was recently removed from Core. No reason why we couldn't implement the Blog API in contrib though.
Does it have a positive or neutral impact on the number of "tightly coupled" connections and dependencies between different parts of Drupal?
No. Nothing in Drupal core currently uses it.
Does its presence significantly improve the experience of first-time evaluators, experienced builders, or developers building on top of Drupal -- without significantly diminishing the experience of the others?
No.
Does it match common patterns and best practices for similar tools and web applications?
No.
RobLoach’s picture

Status: Postponed » Closed (works as designed)

It was moved to xmlrpc module at #1033818: Move xmlrpc includes into xmlrpc.module.

cweagans’s picture

Status: Closed (works as designed) » Needs review

I don't think this should be closed. Splitting XML-RPC off into a separate module just makes it easier to remove, since it's now decoupled from core/includes/*.

I'd really like to see XML-RPC functionality ripped out of core - nobody should be using XML-RPC anymore. Seriously, this is not 2001.

No patch needed:

git rm -rf core/modules/xmlrpc

webchick’s picture

If and when WSCCI offers the ability to export content the way XML-RPC module does (JSON-LD or wahtever), we could look at removing it. Until then though, it seems very premature to reduce our framework's functionality.

fgm’s picture

@cweagans : most (if not all) larger sites depend on XML-RPC still today, including the very latest ones. There was a downtrend around 2009, then mobile use made it surge again, to link mobile apps to servers, with REST still being a tiny minority, when it even exists.

This may be specific to the french market, though, but I would agree with webchick on this one: at some point, this technology, which is very much like function-style programming (remote "procedure" calls), will become obsolete and make room for REST which is very much like object-oriented accessing methods (representations) of a resource using a context (headers). But we're not there yet.

cweagans’s picture

most (if not all) larger sites depend on XML-RPC still today, including the very latest ones.

Sorry, but I don't buy that. I would guess that the majority of Drupal sites have no need for XML-RPC, especially the small ones (remember that the really big sites out there are a small fraction of the people that Drupal is made for). While I do agree that XML-RPC can be useful sometimes, I don't see a problem with running 'drush dl xmlrpc && drush @alias en xmlrpc' before I write my hook_xmlrpc implementation.

Also, having an XML-RPC server for the purpose of linking a mobile app to a server seems to contradict the reason for making Bartik responsive (in my mind, at least). Why bother having a responsive theme in core if we're just going to encourage people to write a mobile app that talks to Drupal via XML-RPC?

This may be specific to the french market, though, but I would agree with webchick on this one: at some point, this technology, which is very much like function-style programming (remote "procedure" calls), will become obsolete and make room for REST which is very much like object-oriented accessing methods (representations) of a resource using a context (headers). But we're not there yet.

We should not be doing things on the basis that "This is how things are now". Drupal 8 will be out for years. Perhaps people are still using XML-RPC now, but there's really no excuse for continuing to use it 3 years from now.

We removed blog.module because it wasn't a good fit for the majority of sites (among other reasons). Why can't we apply that same logic here?

webchick’s picture

Status: Needs review » Postponed

Let's focus attention on making WSCCI happen. If it does, we can revisit this.

cweagans’s picture

Fair enough, I suppose.

kim.pepper’s picture

Issue summary: View changes
Status: Postponed » Needs review
FileSize
61.34 KB

Removes xmlrpc without prejudice :-)

Status: Needs review » Needs work

The last submitted patch, 11: 1285726-remove-xmlrpc-11.patch, failed testing.

kim.pepper’s picture

Status: Needs work » Needs review
FileSize
61.34 KB
612 bytes

Oops.

The last submitted patch, 13: 1285726-remove-xmlrpc-12.patch, failed testing.

InternetDevels’s picture

this patch fix test.

InternetDevels’s picture

moved all to 1 patch

The last submitted patch, 15: 1285726-fix_test-15.patch, failed testing.

Crell’s picture

I thought the update system used XML-RPC, at least at some point. Or am I imagining that?

fgm’s picture

Actually no, it uses XML format, but in a plain HTTP GET request, no XML-RPC. See _update_process_fetch_task() for details.

Regarding this discussion in the larger sense, though, I'm a bit annoyed: @ParisLiakos spent lots of time converting XML-RPC to D8 style with plugins, and I spent most of one week at the Dublin DevDays discussing it with, him, reviewing his patch, tweaking it a bit (basically a PHPdoc, IIRC) so I could mark it as RTBC at the time. But since I had touched it, someone decided I could not RTBC it and reverted it, and, of course, no one else would touch it since then, and the patch no longer applies now. This is a catch-22 situation, apparently.

Most of the arguments in #1 still apply. @Webchick's note in #6, though, is now (almost or fully ?) no longer applicable, because we do have a REST export mechanism, but the XML-RPC server is still far easier to use for client applications, especially in PHP, than REST, so I still do not think reducing our basic framework functionality is appropriate.

kim.pepper’s picture

fgm I understand your pain. I myself spent a large amount of time converting the Aggregator category system over with the help of Paris, only to have it removed later on. At the time I was annoyed, but I had to concede that it wasn't something that core needed to provide, and a better solution could be provided in contrib.

I feel the same way about XML-RPC. Now that we have a REST web service built in, there isn't really a need to have an additional web service interface.

That doesn't mean it can't be maintained in contrib. I understand there will be a lot of use cases for XML-RPC, especially integrating with legacy systems, but I don't think that justifies it being in core.

Kim

sun’s picture

FWIW, to my knowledge, the required maintenance work for xmlrpc.module is close to zero and non-existent (primarily because the code is relatively mature), so I don't think it would bother anyone if it was around for another release.

The only two arguments that I could see:

  1. UX concern: "What's that X-M-L-R-P-C thing and what happens if I enable it?"
  2. DX concern: An additional, separate, procedural PHP4-magic-callback based legacy API for defining route-alike remote procedure callbacks that exists next to a modern RESTful API.

However, IMO (1) doesn't make the situation substantially worse as there's an "RDF", "REST", and "HAL" module already, and (2) is simply what you get to work with if you need to work with a legacy web service protocol.

So if it was just me, then I'd merely consider to move the module into the "Web services" package (apparently new in D8 core) and simply leave this issue alone.

kim.pepper’s picture

I don't think it is as simple as moving it to "Web services" package. Work is progressing on #1979040: Rewrite XML RPC module to services and plugins which would include its own maintenance costs.

Supporting these kinds of legacy modules does have a cost associated with it. The question is whether this cost is carried by core or contrib. I'd prefer contrib.

Kim

vijaycs85’s picture

Priority: Normal » Major
Issue tags: +beta target

OK, we have to come to some conclusion as the issue (#1979040: Rewrite XML RPC module to services and plugins) depends on this issue is a beta-target. Either removing a module from core or adding new API for this service isn't simple in other words needs approval. So making this issue major.

greggles’s picture

IMO, delete the code, let contrib sort it out as/when it can if necessary.

This is not 2001. New sites built on Drupal 8 and sites upgraded to Drupal 8 are very unlikely to still want to or need to use xmlrpc.

kim.pepper’s picture

This is a re-roll of #16, except for the module dependency tests. We'd need to agree on what replacement tests we'd need instead of Forum -> Ban -> XML-RPC.

sun’s picture

#2254203: Fix test performance of Drupal\system\Tests\Module\ModuleApiTest removed that reference to xmlrpc module in (former) module dependency tests. The (fake test) dependency chain mentioned in #25 should no longer exist in HEAD.

Status: Needs review » Needs work

The last submitted patch, 25: 1285726-remove-xmlrpc-25.patch, failed testing.

kim.pepper’s picture

Status: Needs work » Needs review
FileSize
5.53 KB
903 bytes

Removed reference to xmlrpc in Drupal\system\Tests\Bootstrap\GetFilenameUnitTest

greggles’s picture

Great that #28 passes tests, but I think it misses a few files like xmlrpc.server.inc, xmlrpc.module etc. Were you skipping those on purpose?

kim.pepper’s picture

Oops. Actually removes xmlrpc module.

mikl’s picture

Status: Needs review » Reviewed & tested by the community

Looks like you've got it all. Let's get it in :D

alexpott’s picture

Assigned: Unassigned » Dries

I'm +1 for the change.

Assigning to Dries for final decision.

fgm’s picture

Well, things have indeed changed in the two years this has been open. I do not feel as strongly against it as at the time of #1, although I still think it is quite wrong for a server like Drupal to renounce a simple, stable mature WS API.

So let's go with the times and be done with it: as Sun mentioned, the existing code base is old-style, and merging in Paris' and my work for the new version loses the stability and has a significant cost in performance (thanks to plugins) over the procedural version, which is another performance issue we can do without in D8.

greggles’s picture

This isn't about renouncing the simple, stable, mature WS API. Its about deciding what can and can't be supported in core. Lots of standard things exist in contrib and that seems like a perfectly reasonable place for this to me.

sun’s picture

Just in case this happens: Let's copy the current D8 code into https://www.drupal.org/project/xmlrpc before removing it, please.

sun’s picture

Let's copy the current D8 code into …

s/copy/extract/ — Would be great to retain all history that involved 'modules/xmlrpc/' via git filter-branch --index-filter:

http://www.fussylogic.co.uk/blog/?p=1250
http://sgf-dma.blogspot.de/2012/12/git-filter-branch-subdirectory-filter...
http://stackoverflow.com/questions/14759345/how-to-split-a-git-repositor...

mikl’s picture

Let's copy the current D8 code into https://www.drupal.org/project/xmlrpc before removing it, please.

There's no need to wait for that to happen. Even though the code is removed from 8.x, it will always be available in the Git history in case someone wants to recover it later.

kim.pepper’s picture

I did a git subtree split and pushed it up to a sandbox repo: https://www.drupal.org/sandbox/kimpepper/2312139

catch’s picture

Opened the original #1033818: Move xmlrpc includes into xmlrpc.module so +1 here too.

greggles’s picture

Issue summary: View changes

Updated the issue summary with a bit more structure to the decision.

mlhess is running some greps to determine how many Drupal 7 modules depend on incoming xmlrpc requests.

Crell’s picture

Issue summary: View changes

Adding my approval to dropping XML-RPC.

greggles’s picture

Issue summary: View changes

how embarrassing! I left an open tag in the summary.

Damien Tournoud’s picture

+1 from me too.

Dries’s picture

+1 from me as well. Goodbye and thanks for all the fish, XML-RPC.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Noticed a few things in review. Fixing.

alexpott’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
3.9 KB
58.64 KB

Removed all references to XML-RPC that were incorrect and added removal to CHANGELOG.txt

greggles’s picture

Status: Needs review » Reviewed & tested by the community

The interdiff looks good to me. Thanks Alex! Back to RTBC.

I applied the patch and then did a recursive, case-insensitive search for xml*rpc and only found one mention in core/core.api.php

* Web services make it possible for applications and web sites to read and
* update information from other web sites. There are several standard
* techniques for providing web services, including:
* - SOAP: http://en.wikipedia.org/wiki/SOAP SOAP
* - XML-RPC: http://en.wikipedia.org/wiki/XML-RPC
* - REST: http://en.wikipedia.org/wiki/Representational_state_transfer
* Drupal sites can both provide web services and integrate third-party web
* services.

Drupal core no longer provides xml-rpc, but it also doesn't/hasn't provided any tools for SOAP integration as far as I know. I think it should stay there since this block of text is more of a general discussion and xmlrpc will be available in contrib.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.x, thanks!

  • catch committed 6b93ac7 on 8.0.x
    Issue #1285726 by kim.pepper, InternetDevels, alexpott, RobLoach: Remove...
greggles’s picture

Thanks, @catch!

@fgm do you want to be a maintainer of the contrib module?
@kim.pepper depending on the answer, I assume you'll add fgm as a maintainer and promote the sandbox to a full project.

effulgentsia’s picture

Assigned: Dries » Unassigned
kim.pepper’s picture

@kim.pepper depending on the answer, I assume you'll add fgm as a maintainer and promote the sandbox to a full project.

Yep sure.

kim.pepper’s picture

Project promoted here: https://www.drupal.org/project/xmlrpc However, I haven't put my hand up to maintain it, so I'm hoping @fgm will step in.

Also updated link in the change notice.

fgm’s picture

Sure ! +1

kim.pepper’s picture

Great. Thanks @fgm.

Can I be removed as maintainer?

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.