Re: documenting rsync, or, what are we here for anyway? (was: Re: what is rsync)

[Joseph Touch <[e-mail]>]

> On Nov 27, 2020, at 1:53 PM, Salz, Rich <[e-mail]> wrote:
> 
>  
> Everything that HTTP continues to reinvent that was in FTP before there was an HTTP.
> That’s not an answer, of course, but okay.  I guess you meant the list below.
> Yes; it opens a connection per exchange and let’s IP multiplexing do its job. As far back as the mid-90s I noted that HTTP was headed towards reinventing that muxing at the app layer and it now does. That creates a problem of layered multiplexing and how the two interact, esp. for DSCP tagging, among other things.
> The TCP and TLS handshake costs are seen as prohibitive.

They could easily have been handled - e.g., by “priming” additional connections in parallel. I grant that FTP has not evolved in a while and has issues - which could be fixed - but aren’t.

Again, I’m not suggesting using FTP, but it’s inaccurate to claim that FTP is some sort of outdated precursor to HTTP in many ways.

>   I guess not for FTP which isn’t used in e-commerce much.  Might be interesting to code up an FTP script that fetched Amazon’s homepage via TLS. But hey, let’s throw out TCP fastopen and TLS earlydata, too.
> Don’t reinvent multiplexing, for one. Have a common data encoding or support translation. Separate the control channel from the data channel. Support transfer restart. Support parallel transfers without HOL blocking. Support transfers with record boundaries.
> Multiplexing, see above. Common data encoding seems to be mime-types and Accept headers. Restart and record boundaries seem to be covered by byte ranges.  Control channel is a neat idea, I guess that’s QUIC’s stream zero. Or BEEP’s channel zero.  I liked BEEP, too bad the Internet didn’t.

As I said, HTTP keeps trying to “keep up” in many ways (not all, but many) with what FTP had decades ago.

There’s still lessons to be learned there. Those who don’t study history are doomed to repeat it, I suppose.

Joe