URL style syntax in destination?

[Dave Dykstra]

On Wed, Feb 06, 2002 at 01:09:22PM -0500, Alberto Accomazzi wrote:
> Subject: Re: [path] & module options with SSH 
> 
> The discussion about syntax for remote file specification and the exchange
> between Martin and Wayne about configure options for rsh make me wonder if
> we should push some alternative syntax for specifying the transport protocol
> to be used by rsync.  
> 
> I, for one, always stick to the rsync://host/module syntax when pulling from
> an rsync server, and have often wished that the same syntax were available 
> when doing a push.  I find the URL-style syntax easy to remember and understand,
> while the "::" seems much less intuitive (it actually looks perlish to me
> because of the way modules are specified in perl).
> Among other things, I notice that SUN uses the url syntax in its man pages
> describing NFS (they use nfs://host[:port]/pathname).
> 
> So what came to mind is to have rsync recognize and use both for push and
> pull remote specifications of the form:
> 
> 	rsync://host/module/file
> 	ssh://[username@]host/dir/file
> 	rsh://[username@]host/dir/file
> 
> I'm not crazy about the last two, but thought of them while reading messages
> about ssh/rsh issues.  Hmm... one problem that this wouldn't solve is the
> use of ssh-over-rsyncd that somebody has proposed, though.  Also I'm not 
> sure how I would handle the passing of additional options to the external
> transport program (what we do now with -e 'shell [OPTIONS]').  Ok, so 
> maybe this is not so hot, but rsync:// is cool, IMHO.


It seems like there would be some pitfall, but I can't think what it might
be right now.  Web browsers typically only do reading so that's why I think
it was only thought of for the source side.  I looked back through my saved
email, and it was Andrew Tridgell who added the syntax while I was the
primary rsync maintainer.  I didn't find any discussion of whether or not
it should also be on the destination side.  

I suggest that you try implementing it and see how well it fits in and how
clean the implementation is.

I too am not crazy about the rsh and ssh URLs.

- Dave Dykstra