On Mon, 31 Aug 2009, Darryl Green wrote:

> Do you propose then to only support a client to an rsync daemon? Not rsync
> over s shell connection? And without support for the modes implied by
> various rsync options, I guess the protocol simplifies down to something
> fairly basic and file-at-a-time? I do see the utility but it is pretty
> limited compared to a full rsync implementation.

I don't propose anything since I don't think anyone is actually interested
enough or working on any implementation. And as I said before, I'm not even
educated enough on the protocol parts to make any qualified design decisions
for a future possible implmentation. Let's deal with that when the time comes.
If ever.

>> 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.
>
> Ok. I agree. And this explains the lack of a URI syntax - it is particular
> use of data transferred from a perfectly normal http resource that happens
> to have content-type: application/x-zsync to drive the retrieval of data
> (via range requests) from another utterly normal HTTP resource.
>
> However, is there any objection to packaging such an "on top of" protocol
> with libcurl (with options to include/exclude it from the build)? I agree
> you need to draw the line somewhere - otherwise you would end up putting
> mime and http parsers and... in the lib. It seems though, that libcurl is
> about shifting data and so is zsync. It isn't much different from supporting
> (or not) a compressed transfer encoding.

I suppose you're asking this now as someone who's actually willing and
intending to work on making this reality? I just want it clarified and spelled
out, so that we don't just waste time talking about theoretical issues.

First out, I don't want to such decisions on my own like a dictator but I
prefer to hear what regulars on this list etc have to say. We're a project and
community and want to allow everyone to contribute their ideas about where we
go.

I don't think over-HTTP is a final reason to exclude something from libcurl.

-- 
  / daniel.haxx.se