As per http://drupal.org/node/164846 all the XML-RPC server code for the update_status 5.x-1.* clients now lives in a separate, private legacy module on d.o, instead of in the official project* codebase. Now that the update status 5.x-2.0 official release is out, we should just get everyone still running the old 5.x-1.* clients to upgrade. To that end, how about we just have the legacy server code return the hard-coded data about the 5.x-2.0 release of update_status and nothing else? Then, when people view their available updates page, all they'll see is the new recommended release of update_status. Since it won't include any other data, that'll help encourage them to upgrade. ;) Meanwhile, the d.o DB will get a nice break, since it'll no longer be doing this nasty, expensive queries everytime someone checks for updates with a 5.x-1.* client. Attached patch would do the trick. ;)
One question -- would it be cheaper to cache the result of the gzencode() on the hard-coded array? That would save the gzencode(), but would require a DB query to get the cached record. I'm guessing that getting the cached copy from the DB would be faster, but before I put in the code for that, can anyone else on the infra team confirm?
Thanks,
-Derek
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | project_xmlrpc_legacy-update_status-5.x-2.0-only.patch_1.txt | 5.88 KB | dww |
| project_xmlrpc_legacy-update_status-5.x-2.0-only.patch | 7.1 KB | dww |
Comments
Comment #1
dwwHehe, the md5hash and filedate of the official release changed. ;) see http://drupal.org/node/167549 for details.
Comment #2
gábor hojtsyNot sure what kind of review are you looking for here. I don't have access to the private repo where this code is hosted, so I don't have an overall picture. From the looks of the patch, it generates the right data format with the right data input.
Not sure how many 1.x clients are running around, so whether the rest of the computation
base64_encode(gzencode(serialize(...)))makes sense to cache to save some cycles. If the input information is constant, the output of these will be constant as well.Comment #3
dwwI marked this as "needs review" because a) I was hoping someone would comment on the explicit question I asked the rest of the team at the end or the original post, and b) I wanted a peer review of this code before I deployed it on d.o. At the time, there was no drupalorg module, so the private repo was the best place we had for revision control of custom d.o code.
Anyway, I'm tempted to just turn off this module entirely and abandon this patch. update_status 5.x-1.* has been unsupported for 1.5 years. I feel that anyone still running that version should get the 404 they so clearly deserve. ;) Any objections to just totally breaking things for those people at this point?
Comment #4
gregglesWe know pretty specifically now: http://drupal.org/project/usage/update_status
There are ~1-2 users of Update Status 5.x-1.x. Agreed: disable this.
Comment #5
gábor hojtsyYay, disable it. Less to work on the drupal.org upgrading. Also, this would mean all drupal.org modules are now available via public CVS.
Comment #6
dww@greggles: Well, no. update_status 5.x-1.x users don't report usage statistics at all. I'm pretty sure those data points are only there from people manually fetching those files for testing.
That doesn't mean we should keep running this code, but we should use accurate data to make that decision. ;)
Comment #7
gábor hojtsyOK, what is still required here to execute this?
Comment #8
dww- Moved this module into contributions/modules/drupalorg/project_xmlrpc_legacy
- Committed a modified version of the above patch (for update_status 5.x-2.3)
This will be trivial to port now (as in, probably a 1-line change to the .info file), the code is now publicly accessible (now that the drupalorg module exists, which it didn't when this module was added to d.o), and we should stop getting PHP errors in the d.o watchdog tables about bogus queries from the XML-RPC requests for older update_status clients.