On Wed, Feb 23, 2000 at 06:36:07PM +0100, Niels M�ller elucidated:
>
> Hmm. This sounds a little messy. I'm an outsider here, but if I may
> suggest a course for action, I'd would really wish for two independent
> protocols:
>
> S. A nice clean protocol to do the rsync stuff (i.e. transfer of
> files, listing of files. Or any other features that I don't know
> about. This protocol may well be a little verbose.
>
> T. A transport protocol, that performs things like version
> negotiation, user authentication and compression method
> negotiation (typically zlib). At the end of the handshake, this
> protocol provides a bi-directional (possibly packet oriented, if
> that is preferred), typically compressed, channel over which the S
> protocol can be used.
>
> Do you think such a division would hurt rsync efficiency? The nice
> thing about this is that applications that already provide things like
> compression and user authentication can use the S protocol only.
>
> The rsync application could have some options for using either the T+S
> protocol or only S.
What would be wrong with using rcp as a model, like ssh does with scp?
I don't think rsync will gain you much when you are copying new files, it
only really helps when you have changes to a file that already exists.
Then through their algorithm it only copies the changes. I guess it depends
on what would be the greatest usage (for lack of anything better) of "lcp".
Will it be copying occasional new files, or copying the same or similar files
over and over again?
BTW, I think rsync can use ssh to send it's stuff encrypted, I think that
would be a better approach. Just make sure that applications like rsync,
cvs, etc.,. Can use lsh as an rsh substitute.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dale Harris <[EMAIL PROTECTED]> GPG key: 372FBD57 http://www.maybe.org/
Maybe is an Ambivalent Yet Beguiling Enigma
PGP signature
