Improving the rsync protocol (RE: Rsync dies)

Phil Howard phil-rsync at ipal.net
Mon May 20 07:50:04 EST 2002


On Mon, May 20, 2002 at 10:58:33PM +1000, Donovan Baarda wrote:

| On Mon, May 20, 2002 at 09:35:04PM +1000, Martin Pool wrote:
| > On 17 May 2002, Wayne Davison <wayned at users.sourceforge.net> wrote:
| > > On Fri, 17 May 2002, Allen, John L. wrote:
| [...]
| > I've been thinking about this too.  I think the top-level question is
| > 
| >   Start from scratch with a new protocol, or try to work within the
| >   current one?
| 
| tough question... to avoid backwards breakage and yet implement something
| significantly better you would probably have to make two rsyncs in one
| executable; the new protocol, and the old one for a compatible fallback
| talking to old versions. After enough time had passed and all old rsync
| implementations had been purged, the old code could be dropped, leaving a
| nice clean small solution.
| 
| I tend to think that once a delta compressing http extension gets mainstream
| acceptance, rsync will fade away _unless_ it offers significantly better
| performance by avoiding http overheads (which is why ftp lives on, despite
| being a bastard protocol from hell).

I don't see how HTTP can hope to displace RSYNC.  Both have flaws, but HTTP
has way more.  Work is chopping away at them, but the results are often not
very good.  Persistent connections, for example, are a bastardization that
just isn't handled effectively (for example it almost always breaks with
dynamic content such as CGI).

IMHO, it is HTTP that needs to be rewritten entirely from scratch.

Also, I'm really not in favor of so many of these "one size fits all" kinds
of solutions.  An example is XML.  It's a format.  But as we try to overload
it more and more as a solution to all problems, we just end up squishing it
down to being a yet-another-layer in an ever growing stack, which only ends
up with more and more needless layers of software.

As for RSYNC, it has a basic purpose.  As long as it stays focused, then it
can serve that purpose well.  Of course I have ideas to make it better, but
I certainly don't want to see it go away even if none of those are ever
adopted (it's too useful the way it is).

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam at ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------




More information about the rsync mailing list