On 13 Jun 2001, Deven Phillips <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am in the process of gathing up information for the creation of an
> rsync/srsync io slave for KDE.
I'm happy to hear you're interested in working on this.
> I am wondering if I could get your input
> on the best approach. I was thinking about taking rsync, and creating a
> library out of it, and then using that library to handle the
> network/comparison/deltas of the files; but your librsync only handles
> the delta.
Yes, librsync does only handle the delta, and it doesn't particularly
aim to be compatible with the standalone rsync program.
The rsync protocol is a product of evolution, and is frankly pretty
ugly. For example, there's no way to do more than one transfer, or to
move files over a single network connection. Similarly, the protocol
(probably) requires both parties to read the entire list of files in
to memory and sort it before the transfer begins. The protocol is
also fairly tightly tied to the code of the current implementation.
Similarly, error handling is quite hard to get right -- the recent
patch looks like a big improvement in this regard.
To tridge and I, rsync 2.x is essentially in maintenance mode at the
moment: it doesn't seem like a good investment to add more features or
functionality to the codebase. A better way to improve it is to build
a new, cleaner protocol.
I'm quite interested in using the NFS4 protocol, of which we have the
start of a userspace implementation at <http://n4.samba.org/>. This
gives us a standards-based asynchronous RPC protocol that covers all
the basic file operations except for actual delta and patch
operations. If we compatibly extend the protocol to add those
routines, and take their implementation from librsync, then we should
be in good shape.
Of course, this is free software so if you disagree, you're free to do
something different!
So, to be practical, my advice would be that the IO slave should
simply popen() rsync, and keep all the code wrapped up inside the
program. I think we'd certainly be open to patches that make the
output format more easily parsed by programs: separating files in the
listing by nul characters, and similar stuff. Essentially the
protocol doesn't *let* you do anything more flexible than invoking the
program to do one transfer, so I'm not sure that a library could offer
an interface more flexible than that to its callers.
>From a brief browse through the KIO documentation it looks like this
might work out. Perhaps you can write libcallrsync or something, so
that it can later be reused to make a GNOME-VFS method.
> After thinking about it for a while, there should be libs for
> rsh and ssh that I could link in under the librsync for the network
> portions. I may sound stupid, but it has been a while for me with C/C++
> (about 8 years), so please don't flame me for trying.
>
> If you have a few minutes, perhaps you can send my some ideas from the
> perspective of understanding rsync quite well (which I haven't had time
> to become familiar with yet).
Hope that helps,
--
Martin
