[Box Backup] Release Candidate 3

[Dave Bamford]

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.