Date: Tue, 27 May 1997 23:41:54 -0400 (EDT) From: Christopher Sedore <cmsedore@mailbox.syr.edu> To: Terry Lambert <terry@lambert.org> Cc: Ben Black <black@zen.cypher.net>, rssh@cki.ipri.kiev.ua, FreeBSD-Hackers@FreeBSD.ORG Subject: Re: async socket stuff Message-ID: <Pine.SOL.3.95.970527233304.11962D-100000@rodan.syr.edu> In-Reply-To: <199705280034.RAA00781@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 27 May 1997, Terry Lambert wrote: > > > > how do you spell kludge? > > > > > > Why does this qualify as a kludge (and a better question might be "how do > > > you pronounce kludge?" :). > > > > it is a kludge because it is in there for EXACTLY one purpose. you > > couldn't use the facilities for any but transferring a file from one host > > to another. it is only there to get around a general problem for a > > specific application. that's a kludge. > > It's not generally useful, either. For instance, for POP3 and SMTP > mail processing, "." quoting must take place. You have to adulterate > the RFC's and *store* the data quoted (assuming that it will be going > out on the same type of, or similar, transport it came in on) if you > wish to use this facility for, for instance, POP3 lookup or SMTP > forwarding. I was not aware that the RFC's required you to store the data in any particular format on the hosts. I believe you are free to store it any way you choose: quoted, not quoted, encrypted, rot13'd, XORed, compressed, etc. The real problem is with the protocol, not the transfer facilitiy. Any transmission facility that requires in-band quoting will never be high performance. If you want a fast POP server, store the messages in transmission format. Same for SMTP. If you have to gateway, then convert them on input and store them for relay. That this makes more sense in some cases than others I'll readily admit. I still believe that this is primarily a protocol weakness, though. If you want to start talking about places for redesign, let's start with the protocols--they're the main source of the problem. Transmitfile-like APIs would be very general solutions if the protocols had been designed for high-performance transfer in the first place. -Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SOL.3.95.970527233304.11962D-100000>