Justin Erenkrantz wrote:
This seems to be exactly the same number of steps to me. In the current page you select the file and then the mirror. With your idea, you select the mirror and then the file. I don't have any problem with your suggestion, other than the fact that it isn't implemented.You are missing my point: you are creating an extra step that is not needed. There are plenty of solutions to this problem that do not require this level of indirection.For example, you could incorporate the CGI script logic into a shtml file that has a choice list representing each mirror (and method). The links on our download page would be recomputed as you select the mirror. I still prefer a round-robin DNS as that doesn't require any CGI scripting.
> 2. It is extremely simple to configure and maintain. No, it's not. Currently, we have bogus mirrors. For example, I see apache.towardex.com listed as a mirror for me. When I click on the link, it gives me a 404. That is inacceptable. If you want to force users to do this scheme, then you have to ensure that we don't list broken mirrors.
Bullsh**.
1. Most of the mirrors are fine. That particular one is entered in our mirror list incorrectly.
2. Every page lists two guaranteed working sites at the bottom: nagoya and daedelus. I'm thinking of also adding ibiblio to that.
3. If you find a problem with a mirror listing, why don't you fix it rather than complaining about it?
4. Even deadelus is not a guarenteed working site at the moment.
5. Nobody is forced to do anything. Clear links are still provided to http://www.apache.org/dist/httpd/.
> 3. It can be put into place NOW. No, I don't think we can deploy this because we have so many busted mirrors. I'd rather we do the right solution, then do a broken solution. This is a broken solution that will result in too much confusion for our users. Please do not switch to this. -- justin
So would you prefer a state where some users might need to try two or three links to get an actual download, or a state where daedelus is completely unresponsive? If patterns are followed, there is a good chance we could have serious capacity problems on both daedelus and nagoya tommorow morning.
If you have a better solution, then do something about it. We have been talking about this for months, but nobody has stepped forward to actually do it. I implemented the solution that was within my technical and time limits. It is a working solution, and I believe it is superior both from a user point of view and from a resource management point of view.
Joshua.
