This is no proposal for the PXML spec but for the repository one. I think it fits best in this thread.
-----------------------------
OK, I thought about it a bit more and I think there's one additional tag we need. That tag could be generated on the server and doesn't have to be in the PXML.
I have to first explain the setup so this makes sense, please bear with me.
Let's say in the future, we have at least 2 repositories, let's call them RepoA and RepoB. Now, what happens when he client stumbles across a program (same ID, same version) that's on both repositories?
The easy way out, and the way that wouldn't need any change to the repo definition, is to just priorize sources in the client, for example the higher up a repo is in the settings, the higher priority it has. This way, when stumbling over an app with the same ID and version on multiple repos, you just take the title, description, etc from the higher priorized one and eventually download the package from the same.
But now, the efficient way to handle it is.. when you have the same program on multiple servers, which you will have since most people would probably upload their stuff to all repos and the repos would synchronize with each other, then you would balance the downloading between servers. Download app 1 from RepoA, App 2 from RepoB, app 3 again from RepoA etc. One could even go the way of some download managers and get the first part of an app from the first repository and the second part of it from another repository.
I'm sure you all agree that this way would be preferable, after all, it would serve as a client side load balancing, which is easier on the servers and will probably result in faster download speeds for the end user. But this approach has two downfalls:
1. when using the download manager approach, you have to be absolutely sure that the file on all repositories is the same on a binary level. Now, if whoever made the app uploaded it on RepoA and then repackaged it without changing it for some reason and then uploaded it to RepoB, the app, while being the same one, wouldn't be the same on a binary level, so the dl-manager-approach would fail. Now, I do not know if the server needs to implement something special for the client to be able to download only the second part of a file, so this approach would maybe not work anyway, but that brings us to..
2. what happens when the two apps, both with the same ID and the same version tag, weren't the same app? Sure, the chances of two devs choosing the same ID and version and uploading it on different repos are rather slim, but it is possible. Also, never underestimate the douchebagginess of humans. Say GuyA uploads his prog to RepoA. GuyB hates the guts of GuyA and therefore makes a small malicious app (or a really buggy one) and intentionally uses the ID and the version tag of the one GuyA made and uploads it to RepoB. This way, GuyB could be sure that half of the time, people would get his malicious version instead of the real one but blame GuyA for it.
So, long story short, what could be done about those two problems? The answer brings us back to the start of this post and the tag I want to propose. The tag would be a hash (CRC, MD5, doesn't really matter). If one had a hash tag, the client can act like this: If a program with the same ID and version is on multiple repositories, get the hash tag of the one in the highest-priorized repository. Then, balance the downloading between that highest-priority repo and all other repos which have the same program (again, id and version) with the same hash tag, but ignore all repositories that, while having the same ID and version, do not have the same hash tag.
This would solve both problems mentioned above.
1: The hash ensures that all the repos you download from have the files in exactly the same (on a binary level) version, so repackaging for whatever reason would no longer be a concern for you.
2: The hash ensures that you will get the right app and not some other one that's just an impostor. Sure, if the malicious version was on your highest-priorized repo, you would still get it, but one can assume that you would priorize the largest repo (or the offizial one, if there will be one) at the top and that, in turn, the original dev of the app you want would upload it on the largest/official repo, so the impostor would have to resort to another, smaller repo.
TL/DR:
I propose a hash tag that is generated repository side at upload time.
Holy canolli, this post grew huge. Why the fuck do I always use so many words to explain something so simple, in the process probably making it harder to understand than if I just made it short?