On Sun, 2009-08-30 at 13:27 +0200, Daniel Stenberg wrote:
> On Sun, 30 Aug 2009, Darryl Green wrote:
[snip]
> 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.
>

Ok. I suppose I'm just thinking of removing it as some form of backlog
maintenance (ie if it won't ever happen why list it) - I'm not against
it being implemented.

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

Makes sense.

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

Well - aside from the official url syntax, there is certainly an at
least implied syntax here: http://www.samba.org/ftp/rsync/rsync.html

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

Ok - I overstated it - it is implementable if you reduce the scope of
functionality to single file transfer and daemon mode.

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

Drawback #1 is partly due to the lack of a truly portable implementation
I feel.

Drawback #2 is I think an aspect of your point below - so I'll address
it there.

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

Ok. Thanks for the feedback. If there is interest in including it I'm
happy enough to have a go at implementing it myself.

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

Yep - that would be me about zsync...

> If nobody wants to do
> it then having it in the TODO doesn't help a lot...

True. See above re triage of the todo by removing zsync...

Regards
Darryl.
Received on 2009-08-31