superlifter design notes and rZync feedback

[Ben Escoto]

>>>>> "MP" == Martin Pool <mbp at samba.org>
>>>>> wrote the following on Fri, 19 Jul 2002 14:04:08 +1000

  MP> I think that's a good way to play it, because there is enough
  MP> work in each section that they're non-trivial layers, but
  MP> they're also sufficiently separate to allow a lot of good
  MP> experimentation or adaption.

Also I think that experienced programmers are often very generous in
what they consider trivial.  You and Wayne know a lot about protocols,
so something trivial to you could be far from it to someone else.
They could learn a lot from what you didn't do as well as what you
did.

    To take an example, I probably wouldn't have written rdiff-backup
if librsync didn't package the "trivial" command line app rdiff.  Why?
Well, the first version of rdiff-backup was < 1000 lines, and I wrote
it largely for my personal use.  Right now the python librsync wrapper
rdiff-backup uses is about 600 lines, and that would have been 60%
more work.  Doing trivial things for other people can really lower the
barrier for further innovation (cliched but true I think).

    For another data point, Slashdot had a discussion of BEEP
recently.  The impression I got was that people thought it filled a
valuable role and some were excited by it, but the implementation was
very controversial.  So perhaps something like BEEP but aimed at a
slightly different audience would be popular.

  MP> working only at layer 4, you'd be able to implement a client
  MP> that could detect remote renames (by scanning for files with the
  MP> same size, looking at their checksums, etc.)

It might also work in some cases to write down inode numbers.  (At the
risk of abandoning the "don't save any information between sessions"
principle.)


-- 
Ben Escoto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.samba.org/archive/rsync/attachments/20020719/a4b64e60/attachment.bin