Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#46 | 1285726.46.patch | 58.64 KB | alexpott |
#46 | 30-46-interdiff.txt | 3.9 KB | alexpott |
#30 | interdiff.txt | 49.21 KB | kim.pepper |
#30 | 1285726-remove-xmlrpc-30.patch | 54.74 KB | kim.pepper |
#28 | interdiff.txt | 903 bytes | kim.pepper |
Comments
Comment #1
fgmI 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.
Comment #2
sun@fgm: Thanks for your subsystem maintainer perspective!
The reasons for postponing this are:
Comment #3
RobLoachI 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:
Comment #4
RobLoachIt was moved to xmlrpc module at #1033818: Move xmlrpc includes into xmlrpc.module.
Comment #5
cweagansI 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
Comment #6
webchickIf 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.
Comment #7
fgm@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.
Comment #8
cweagansSorry, 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?
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?
Comment #9
webchickLet's focus attention on making WSCCI happen. If it does, we can revisit this.
Comment #10
cweagansFair enough, I suppose.
Comment #11
kim.pepperRemoves xmlrpc without prejudice :-)
Comment #13
kim.pepperOops.
Comment #15
InternetDevels CreditAttribution: InternetDevels commentedthis patch fix test.
Comment #16
InternetDevels CreditAttribution: InternetDevels commentedmoved all to 1 patch
Comment #18
Crell CreditAttribution: Crell commentedI thought the update system used XML-RPC, at least at some point. Or am I imagining that?
Comment #19
fgmActually 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.
Comment #20
kim.pepperfgm 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
Comment #21
sunFWIW, 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:
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.
Comment #22
kim.pepperI 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
Comment #23
vijaycs85OK, 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.
Comment #24
gregglesIMO, 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.
Comment #25
kim.pepperThis 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.
Comment #26
sun#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.
Comment #28
kim.pepperRemoved reference to xmlrpc in
Drupal\system\Tests\Bootstrap\GetFilenameUnitTest
Comment #29
gregglesGreat 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?
Comment #30
kim.pepperOops. Actually removes xmlrpc module.
Comment #31
mikl CreditAttribution: mikl commentedLooks like you've got it all. Let's get it in :D
Comment #32
alexpottI'm +1 for the change.
Assigning to Dries for final decision.
Comment #33
fgmWell, 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.
Comment #34
gregglesThis 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.
Comment #35
sunJust in case this happens: Let's copy the current D8 code into https://www.drupal.org/project/xmlrpc before removing it, please.
Comment #36
suns/copy/extract/ — Would be great to retain all history that involved
'modules/xmlrpc/'
viagit 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...
Comment #37
mikl CreditAttribution: mikl commentedThere'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.
Comment #38
kim.pepperI did a git subtree split and pushed it up to a sandbox repo: https://www.drupal.org/sandbox/kimpepper/2312139
Comment #39
catchOpened the original #1033818: Move xmlrpc includes into xmlrpc.module so +1 here too.
Comment #40
gregglesUpdated 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.
Comment #41
Crell CreditAttribution: Crell commentedAdding my approval to dropping XML-RPC.
Comment #42
greggleshow embarrassing! I left an open tag in the summary.
Comment #43
Damien Tournoud CreditAttribution: Damien Tournoud commented+1 from me too.
Comment #44
Dries CreditAttribution: Dries commented+1 from me as well. Goodbye and thanks for all the fish, XML-RPC.
Comment #45
alexpottNoticed a few things in review. Fixing.
Comment #46
alexpottRemoved all references to XML-RPC that were incorrect and added removal to CHANGELOG.txt
Comment #47
gregglesThe 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
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.
Comment #48
catchCommitted/pushed to 8.x, thanks!
Comment #50
gregglesThanks, @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.
Comment #51
effulgentsia CreditAttribution: effulgentsia commentedComment #52
kim.pepperYep sure.
Comment #53
kim.pepperProject 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.
Comment #54
fgmSure ! +1
Comment #55
kim.pepperGreat. Thanks @fgm.
Can I be removed as maintainer?