[Box Backup] Release Candidate 3

Dave Bamford boxbackup@fluffy.co.uk
Sun, 19 Feb 2006 20:56:09 +0000

Ben Summers wrote:

> On 19 Feb 2006, at 17:47, Martin Ebourne wrote:
>> On Sun, 2006-02-19 at 17:40 +0000, Chris Wilson wrote:
>>> Hi Ben,
>>> On Sun, 19 Feb 2006, Ben Summers wrote:
>>>> I "broke" backwards compatibility by bumping the protocol number
>>>> because...
>>>> * A 0.10 server will appear talk to a 0.09 server just fine.
>>> Sorry, what I meant was, is there no way that the server can be  
>>> made to
>>> accept clients with a protocol version older than the highest one it
>>> supports, if there are no backwards-incompatible changes in the  
>>> protocol,
>>> as is the case here?
>>> Forcing the server and client protocol versions to match exactly,  
>>> while
>>> conservative, is a real pain for server operators and users, IMHO.
>> I agree that we should try and address this. Really it must be  possible
>> to upgrade one end without the other. Possibly not either way  round, it
>> would be ok for instance if the server always had to be >= the client.
>> Not sure how the protocol works, but if the client sends its  version to
>> the server, maybe the server could respond with the same version if  and
>> only if it can offer compatibility. Otherwise it responds with its own
>> version.
> There's a Version() command exactly for this. It'll do what we want.
>> This doesn't sound like something we can address this time round  
>> though.
> Writing an automated test for it will be a nightmare! And this will  
> really need an automated test because the implications of getting it  
> wrong are so bad.
> Ben

Would it be possible to run both the old and new version of the server 
on the
same machine? Maybe with 2 different areas for the data. Or is this totally
out of the question. Perhaps they would have to listen on different ports?
I don't know enough about the code.

Just an idea ?

Dave Bamford.