and clicking that would automatically download a patch and create shortcuts.
This has the advantage of true decentralization: We would no longer need the approval of another node in the network that lists a certain repository. Instead, people can download the patch directly from your site.
The basic code to register such an URI scheme is very simple. You just have to add a bunch of registry keys and make thcrap respond to those parameters. This can be done automatically each time you run thcrap.
This might seem to forgo patch stack configuration entirely in favor of usability, but I can think of two ways to fix that:
One way would simply run thcrap_configure normally, but ensure the given repository to be present in the patch list:
This would automatically add the English patch below the Mima patch.
As you see, you can either give the complete URL to a patch, or its repo/patch ID.
With the repo/patch ID combination, thcrap would of course need a way to actually locate the patch download. For "well-known" repositories like thpatch or nmlgc, this is no problem - these are always included in the distribution. Otherwise, thcrap will do a recursive neighbor search across all the servers it knows - and, what makes this really powerful, also all the servers directly specified as URLs in the link.
This means that repositories simply need to list URLs of all the servers they need as its neighbors (which is best practice anyway), and you're guaranteed to get the right patches.
Instead of directing your users to the thcrap download site, you would simply have a custom URL like
and clicking that would automatically download a patch and create shortcuts.
This has the advantage of true decentralization: We would no longer need the approval of another node in the network that lists a certain repository. Instead, people can download the patch directly from your site.
The basic code to register such an URI scheme is very simple. You just have to add a bunch of registry keys and make thcrap respond to those parameters. This can be done automatically each time you run thcrap.
This might seem to forgo patch stack configuration entirely in favor of usability, but I can think of two ways to fix that:
One way would simply run thcrap_configure normally, but ensure the given repository to be present in the patch list:
In fact, since all required functionality for this is already present in thcrap_configure, I could add this scheme immediately.
Another way would be to provide multiple pre-configured stacks on your site, which all would be able to be set up with one click:
This would automatically add the English patch below the Mima patch.
As you see, you can either give the complete URL to a patch, or its repo/patch ID.
With the repo/patch ID combination, thcrap would of course need a way to actually locate the patch download. For "well-known" repositories like
thpatchornmlgc, this is no problem - these are always included in the distribution. Otherwise, thcrap will do a recursive neighbor search across all the servers it knows - and, what makes this really powerful, also all the servers directly specified as URLs in the link.This means that repositories simply need to list URLs of all the servers they need as its neighbors (which is best practice anyway), and you're guaranteed to get the right patches.