>The FTP server we are using (proftpd) places restrictions on how we >store files in the file sytem that are much more constraining than >the http and rsync daemons. Essentially, the files to be served must >be stored in a single tree (as hardlinks - symlinks won't work). >This is impeding work as we evolve. In particular, it affects how we >separate services to take advantage of cloud architectures. Other >servers have different limits, but still place significant >constraints on what we can do. Since the information is already >available through other mechanisms (particularly rsync), the folks >studying the problem recommended discontinuing the service, rather >than investing in finding the least onerous deamon and reconfiguring >to it. Surely you could leave a FTP server whose copies of the files are just pulled out of the cloud server and put the right proftpd form, and now you can continue to offer legacy ftp access for the cases where there are old ftp: URLs. Then you can reconfigure your CDN multi-homed redundant cloud services as much as you want, and not risk making more IETF URLs uncool because you don’t think URL stability is important enough. I don’t see how doing this would “impede work” or affect how you plan to separate services (you know, by separating the ftp server) or place any significant constraints on what you can do (except please don’t break http: URLs either). Larry — http://larry.masinter.net