On Sun, 30 Aug 2009, Darryl Green wrote:

> 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

The TODO document lists a lot of ideas. They are mentioned in there as they
have not (yet) been dismissed, but that doesn't mean everything in it are good
ideas. I think basically all of the stuff there could be taken here for
discussion before any larger effort is put into it.

When it comes to protocols, I'm generally open to support just about all
application protocols that match the paradigms: they transfer data and that
data can be specified with a URL/URI.

I don't think rsync differs a lot from a lot of other protocols in the
transfer related parts so I could see why someone would like to see it
supported. It doesn't seem to have a defined URL syntax yet, but there's a
draft: http://tools.ietf.org/html/draft-weiler-rsync-uri-01

> I think it is unimplementable and should be removed

I disagree, although I must confess I don't know about much of the actual
rsync protocol parts.

> zsync is a lesser known use of the rsync algorithm for optimizing downloads
> of updated versions of files over http.

> 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.

To me it has about the same level of reason. But it has two drawbacks compared
to rsync: 1) it's not very known or widespread and not to ignore: 2) there's
no URI format for it.

There's also the little quirk that protocols ON TOP of HTTP really doesn't
need to be implemented within libcurl, but could also quite easily and
effectively instead be written as a user of libcurl. So I'm not sure I agree
that HTTP-based protocols need to be support by libcurl itself.

> 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?

I'm interested in everything that develops libcurl and in data transfer
technologies in general, but I'm not prepared to dive in into this particular
thing right now. I've got too much other stuff to mess with.

> Is it worth making it a todo?

Unfortunately, I think adding it to the TODO has very little value: if someone
wants to work on it then I figure that someone will do it or at least say
something about it here even if not present in the TODO. If nobody wants to do
it then having it in the TODO doesn't help a lot...

-- 
  / daniel.haxx.se