On Wed, Jul 21, 2010 at 8:20 PM, P.J. Eby <[email protected]> wrote: > At 01:10 PM 7/21/2010 +0100, Paul Nasrat wrote: >> >> Given the fragility of this it seems that we might want to consider >> alternative mirrorlist discovery mechanism.
> Non-random selection is tougher to implement, since you'd need to keep some > kind of history to make it work effectively. Determining the length of the > list is a trivial problem by comparison. Sure, it's not a hard problem in terms of computer science, but having a well defined way to do this for mirroring, dependency resolving and other clients seems like a reasonable request. But that selection is going to be the responsibility of the clients, some may take the hit to maintain a history and periodically update or generate a confing (cf fastestmirror plugin to yum or netselect-apt). >From just picking up the PEP, reading it and using the information therein to write a client implementation I think that the current documented client code snippet does not do what the description intends. It could be I'm misreading this, so if it is not the intent that clients should be able to generate a list of mirrors to operate on via last.pypi.python.org. Is there any technical reason you'd want pypi clients to binary search DNS to find the mirror end rather than a more directed lookup? Paul _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
