On Sat, Mar 27, 2010 at 08:52:22PM -0800, Arthur Corliss wrote: > On Sat, 27 Mar 2010, Elaine Ashton wrote: > > >Actually, I thought I was merely offering my opinion both as the sysadmin > >for the canonical CPAN mothership and as an end-user. If that makes me a > >prick, well, I suppose I should go out and buy one :) > > :-) You'll have to pardon my indiscriminate epithets. The barbs are coming > from multiple directions. My point still stands, however. Your experience, > however worthy, has zero bearing on whether or not my experience is > just as worthy. Even moreso when you guys have zero clue who you're talking
Are you running a large public mirror site, where you don't even have knowledge of who is mirroring from you? (Not even knowledge, let alone channels of communication with, let alone control over) Because (as I see it, not having done any of this) the logistics of that is going to have as much bearing on trying to change protocols as the actual technical merits of the protocol itself. Most of the cost of rsync is an externality to the clients. If one has an existing mirror, one is using rsync to keep it up to date, what's the incentive to change? > Sounds like you may be hamstrung by your own bureacracy, but that's rarely > the case in most the places I've worked. Not to mention that between > passive mode FTP or even using an HTTP proxy (most of which support FTP > requests) what I'm proposing is relatively painless, simple, and easy to > secure. This concern I suspect is a non-issue for most mirror operators. > Even if it was, allow them to pull it via HTTP for all I care. Either one > is significantly more efficient than rsync. I'm missing something here, I suspect. How can HTTP be more efficient than rsync? The only obvious method to me of mirroring a CPAN site by HTTP is to instruct a client (such as wget) to get it all. In which case, in the course of doing this the client is going to recurse over the entire directory tree of the server, which, I thought, was functionally equivalent to the behaviour of the rsync server. Nicholas Clark
