Removed /xmlrpc endpoint

[bmispelon]

This endpoint doesn't seem to be used in practice (3 hits in the access logs in the past ~2 months). It also introduces a maintenance burden, and the instructions it gives don't actually work.

[claudep]

I would be OK for this change. However, it would be great to know what motivated its introduction in the first place to ensure the use case is now obsolete. Did you find anything in its history?

[bmispelon]

I would be OK for this change. However, it would be great to know what motivated its introduction in the first place to ensure the use case is now obsolete. Did you find anything in its history?

As far as I can tell, the xmlrpc plugin has been installed since initial release of the site. I did find a page on the wiki (last edited 11 years ago) that mentions it: https://code.djangoproject.com/wiki/OpenData#trac-s-rpc-interface
So it seems it may have been installed as a way to give the community access to the trac data (I contacted Jacob a few months back to get some details but haven't heard back).

I think having a regular database dump would be a better way. It's something I've had in the back of my TODO list for a few months, but it's not as straightforward as I'd hoped (mostly because some of the data needs to be anonymized/sanitized before we can make it public).

[claudep]

Thanks, then I think it is the good move, and we can always revert if we realize at some point that the functionality is essential to some service.

[laymonage]

Hey y'all. Looks like the same XmlRpcPlugin is also responsible for the JSON RPC (/jsonrpc endpoint). The endpoint seems useful for extracting data to gain insights, e.g.

• the "Who contributed to Django X.Y?" project by Katie from DjangoCon Europe 2022: https://github.com/glasnt/dceu2022-sprints-work
• demo by Tobias from this gist: https://gist.github.com/rixx/422392d2aa580b5d286e585418bf6915

Shall we revert this?

If a regular DB dump is preferred, I'm happy too. As long as there's a way to get a recent-ish snapshot... 😄

[glasnt]

If memory serves, I originally got this code from Rixx's gist. It's entirely possible we were the only two consumers of this endpoint.

If there is an alternative interface, I'd be happy to migrate.

[bmispelon]

Instead of restoring the old API, I'd like to propose creating our own: django/djangoproject.com#1656 (draft PR)

This would allow retrieving multiple (all?) tickets at once and would let us control the output better (the previous API was leaking some potential minimally sensitive data).

What do you think?

[pauloxnet]

Since this PR is merged, can we create a new issue to track the problem and the new implementation or the revert? Otherwise it is very difficult to find.

[laymonage]

@pauloxnet good point! I've created an issue: django/djangoproject.com#1657

@bmispelon If it's not too much work, I think creating our own API would be great! I'll have a look at the PR this weekend. Thank you 🤗