Hi,

First thanks for a great lib/tool that is easy to use (it must be - I've
never posted on any curl list before..) and powerful.

I see that there is (still) a todo for rsync support in libcurl.
Frankly, I think it is unimplementable and should be removed - because
the rsync protocol is a very efficient but almost "stream of
consciousness" transfer between 3 parties (yes 3) and short of making
rsync itself a library I can't see a way to "incorporate" it in anything
else. Note that librsync is not rsync protocol - it is a library
implementing the rsync *algorithm* and in practice a tool for producing
"rdiff's". There is no way to use librsync to implement the rsync
protocol. rsnc doesn't use librsync... In addition, rsync itself is a
fairly complex and powerful tool - it isn't really "just" a protocol for
transferring data.

However, zsync is a lesser known use of the rsync algorithm for
optimizing downloads of updated versions of files over http. It uses a
"clever" client but doesn't require a special server component (unlike
rsync) - it just uses any std http server that has range support, plus
relies on a server-side utility to produce (when the content is updated)
a .zsync file on the server (well - it needn't be run on the server of
course - the .zsync file can be uploaded to it as part of a content
update).

Anyway, it seems to me that zsync would be more widely used if it were
able to be used as just a way (rather than the way) of doing a transfer
and that incorporating it into libcurl would make a lot of sense. Also,
zsync would benefit from many of the facilities already implemented for
http (and inherently reusable for zsync) in libcurl. It is also likely
that by using the libcurl http support many of the portability issues of
zsync (to non-posix platforms) could be resolved easily. Is anyone else
interested in this? Is it worth making it a todo?

Regards
Darryl
Received on 2009-08-30