On Tue, Feb 13, 2001 at 03:06:29PM -0600, Dave Dykstra wrote:
>
> It hasn't been done, and it's not a good idea because the protocol that the
> rsync program uses is not intended to be general or have more than one
> implementation. It is highly optimized for the one application. There are
> even many cases in the code where version numbers are checked in order to
> know what the other side is expecting.
>
> What exactly did you want to do with the library?
I've been a real big proponent of rsync here and I've used it all over
the place to rip the use of NFS out of production. I've even gone so
far as to have an rexec command that uses rsync to run a command 'over
rsync'. Ie, instead of running a program like "command -options" you
run it as "host::module/command -options" and it handles pulling down
the program and caching it locally and what have you. I also pull over
configuration files in a similar manner.
What I had an idea to do was take this a step further and have the
ability to say ropen(), and create a filehandle from within a program
that was linked to rsyncd. Instead of having a config file local or
reading it over NFS or pulling the entire thing local with the rsync
client and then reading it (what I currently do), the file handle would
have direct access to the rsyncd.
This would just remove the necessicity of calling the rsync program
itself to accomplish this. The rsyncd protocol might not be robust
enough to handle this but I thought it was worth a shot to try. This
is why I am asking. :-)
Thanks,
--
Phillip Moore | Cluster Administrator
[EMAIL PROTECTED] | "If you don't know what you're doing,
650.653.2895 | don't do it on a large scale." - Tom Gilb
