|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ARIN Policy on IP-based Web Hosting
>> Until this happens, I can see no viable alternative to FTP. > >HTTP, perchance? The only things missing are a machine-parsable file >indexing method (which would be easy enough to standardize on if someone >felt the need to do so; think a "text/directory" MIME type, which would >benefit more than just HTTP, or use a multipart list of URLs), and >server-to-server transfers coordinated from your client, which most people >have disabled anyway for security reasons. > >But, you get the added benefit of MIME typing, human-beneficial markup, >caching if you have a nearby cache, inherent firewall friendliness (no >data connection foolishness), and simple negotiation of encrypted >transfers (SSL). And for command-line people like myself, there's lynx, >w3m, and wget. http is a good idea, but... "mime typing"? i don't want a program that's gonna tell me what i have to do with my data, or with whihc program i will have to open it later. my data belongs in a file, exactly as i requested it. with the appropriate line-termination, of course, which http doesn't do. ""human-beneficial markup"? you just said we need a "machine-parsable file indexing method". what do we need humans for? caching usually gets in the way. "no data connection foolishness" translates to no way to abort a connection other than by dropping it, reconnecting, and exchanging authenticators again. highly inefficient. >FTP is disturbingly behind on features, some of which (decent certificate >authentication, full-transaction encryption, data type labelling, and >cache usefulness) are becoming more important today. Either the FTP RFC >needs a near-complete overhaul, or the HTTP and other RFCs need to be >updated to include the missing functionality. two things would improve ftp: some sort of tls for the control channel (and maybe the data channel as well), and kernel support for the data channel. all i mean by this is the ftpd opens the file to be sent, the socket to which the data needs to be read, and passes them both to the kernel saying "splice these together, would you?" no more kernel- to-userland-and-back copies, the kernel will *know* when the receiver can take more data, and the ftpd can "abor" whenever it needs to by closing the data socket. this feature would, of course, be mutually exclusive with the optional encryption. -- |-----< "CODE WARRIOR" >-----| [email protected] * "ah! i see you have the internet [email protected] (Andrew Brown) that goes *ping*!" [email protected] * "information is power -- share the wealth."
|