On Feb 04, 2015, at 08:08 AM, Donald Stufft wrote: >If it gets implemented it'll live at /uscan/ because it exists primarily to >work around the deficiencies that exist in uscan (Particularly the dificulty >in ignoring url fragments). Everyone else should just use the URLs at /simple/ >which most systems use with no problem because they can parse the URLs and >ignore the URL fragments (or use them for verifying the hash if need be).
I'll just note that I've found the fragments inconvenient in other settings too. They aren't very user friendly since (IMHO) they add noise that users cutting and pasting urls generally don't care about. They also "feel" odd in that the md5 checksum doesn't fit what I think as a typical fragment. Traditionally, they are used to point to an anchor (sub-resource) within the parent resource. That's not the case here. http://en.wikipedia.org/wiki/Fragment_identifier has this to say: """ Several proposals have been made for fragment identifiers for use with plain text documents (which cannot store anchor metadata), or to refer to locations within HTML documents in which the author has not used anchor tags: As of September 2012 the Media Fragments URI 1.0 (basic) is a W3C Recommendation.[12] The Python Package Index appends the MD5 hash of a file to the URL as a fragment identifier.[13] If MD5 were unbroken (it is a broken hash function), it could be used to ensure the integrity of the package. https://pypi.python.org ... zodbbrowser-0.3.1.tar.gz#md5=38dc89f294b24691d3f0d893ed3c119c """ So even without the uscan incompatibility (which is just one of the two factors leading to noisy d/watch file), I think there's some value in fragment-less URLs. I understand the checksum isn't being used cryptographically here, but maybe thinking ahead to the use of more secure algorithms in the future can lead to a more flexible design: Legacy (if it indeed needs to be kept for backward compatibility): /simple/foo-x.y.z#md5=blah then: /simple/plain/foo-x.y.z /simple/sha256/foo-x.y.z#sha256=blah etc. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150204100749.00106...@anarchist.wooz.org