[Catalog-sig] PyPI and PEP 381

["Martin v. Löwis"]

> 1. /update
> 
> receives a payload with a timestamp to tell the mirror to update
> itself the mirror should use that timestamp to compare it to its own
> "last-modified" timestamp.
> 
> 2. /update/<project-name>/<version>
> 
> receives metadata of each project (same metadata the XML-RPC API
> uses) as well as a timestamp.

What's the purpose of the second URL? Isn't the first one sufficient?
And what is the version number for (what if there isn't really one, as
in project creation or deletion)?

Also, it would be possible to drop the timestamp from the first URL -
why have it?

> Correct me if I'm wrong, but I believe the XML-RPC API is capable of
> providing that information already. Once the mirror gained the list
> of projects still to be updated, it would mirror them "manually".

Exactly so, through the changelog call. It would actually be possible
to use that also in the /update URL.

> Actually this wouldn't differ from the PEP: starting with trusted
> mirrors. And I absolutely agree with what you earlier said, to slowly
> start with such a new feature.

Ok, but if there is no immediate need for such a feature outside of
mirroring, I'd really like to propose that this tight synchronization
for mirroring is unnecessary. Even with your proposed protocol, a
mirror might still be out of date (assuming PyPI notifies
asynchronously, which it IMO should). So applications that expect a
release to be available on all mirrors right after the POST to
PyPI returns would still find that they have to wait "somewhat".

Regards,
Martin