On Fri, 2002-07-12 at 17:01, Martin Pool wrote: > I think the main questions are: > > - do people actually want all that flexibility? > > - is it worth starting from scratch? > > - is this a reasonable way to go > > You can see the current thoughts here: > > http://samba.org/~mbp/superlifter/ > > I'd appreciate any comments you might have.
When I read this, the first thing that came to my mind was a project that had three parts: 1. The specification for an abstract protocol designed to allow a single threaded application get good performance using a single, possibly low bandwidth/high latency pipe. No specific file commands would enter in at this stage, but error reporting and recovery, some kind of security policy, and some other stuff I'm omitting would be included. 2. A library to make it easy for applications to work with protocols that have the form in 1. A well-written interface to a scripting language (probably python) would be considered a core part of this. 3. Specification for a more specific, rsync-like protocol, and maybe another library (again with at least a scripting wrapper) to make it easy for applications to implement the protocol. 4. The model application rsync3 which shows off what the protocol can do. Ideally this part should be really short and sweet. The end result could be to let people develop different applications very easily which have the power of rsync. For instance, perhaps something like rdiff-backup could have used the protocol defined in step 3, and maybe even an unmodified rsync server, and turn out faster than it currently is. Other people could use the tools to do something with encrypted files, and maybe their app wouldn't use the rsync algorithm at all. Is all this a good idea? I have no idea, it is just what came to my mind when I read your design notes. But it does appear that some areas of the project (like debating ":" vs "::") have little to do with other areas (like TCP vs UDP, apache server mod). I'm not sure how much "market research" you have, but if you just create a better rsync it might be hard to know how many people that would help and how many find rsync good enough. The above approach could be a hedge against that because it could be used for a lot of stuff and if you make it easy enough to work with (say with the scripting support, simple APIs) I'm sure other people will dream cool stuff up. This message is longer than I intended - it's always dangerous to write volumes on something I know nothing about :-) -- Ben Escoto
signature.asc
Description: This is a digitally signed message part