2000-11-02-19:23:39 Martin Pool:
> My feeling is that eventually the existing code will suffer metal
> fatigue from all these changes. Sooner or later we should pull the
> core algorithm out and put it into a new framework and protocol.
> Scripting will be an important part of that, though there are
> still some fundamental questions undecided, [...]
I'm a keen fan of restructuring to support scripting.
There are, obviously, very different approaches that can be taken.
My own personal favourite is to isolate the truly tricky bits --- in
our case, the rsync algorithm, and the code to do awesomly close to
utterly perfect replication of all attributes of a filesystem
(reader/writer logic), and perhaps some other bits I haven't thought
of --- into one or more libraries with documented interfaces. If you
can library-ize all the functionality, then you can ship a
standalone utility with a main.c that does very little, and offer a
menu of bindings to scripting languages of all sizes and shapes. For
a utility like rsync, it'd seem to me a shame to hook it permanently
and irrevocably into any of perl, python, guile, or anything other
language that's many many times bigger than all of rsync; if we
wanted to avoid having our own C standalone driver, I'd push for the
minimal scripting language to be shipped with it to be something
like Lua, which would increase the size of rsync by c. 1/3-1/2, if
we didn't migrate any of the functionality that's currently in rsync
into (more compact) Lua.
-Bennett
PGP signature
