Re: version negotiation

This sounds like generally a good direction to me, but I don't understand
the details yet.

One tiny correction:

My understanding is that right now, unison simply assumes that the
> remote side speaks the same protocol, and things deteriorate from there
> if it is not true (because of a 2.48/2.51 mismatch).
>

There's an explicit check for version number compatibility, not an
assumption.  So things don't deteriorate; they just stop.  :-)

Keeping socket mode seems like a good idea if possible.  I do think there
are people out there with useful use cases.  (Unison gets applied an an
astonishing range of situations.)

You're probably already thinking about this, but one critical aspect of
protocol negotiation is the set of preferences that each side supports.  We
did take the step a few years ago of introducing "client-only" preferences,
which can be added without bumping the protocol number.  But this scheme is
getting fancier than that!

  2.51.5 will simply announce as 2.51.5
>
>   2.51.5, if it sees the remote as 2.51.5 or higher, instead of starting
>   the old protocol, will send the first message of the "determine
>   supported proto versions negotiation protocol".  If it sees something
>   earlier, it will just do the old protocol.
>

I'm not 100% clear how this will work.  If the *type* of some data
structure changes, then how will the code be able to switch protocols
without some kind of translation layer?

   - B


>

_______________________________________________
Unison-hackers mailing list
[email protected]
https://LISTS.SEAS.UPENN.EDU/mailman/listinfo/unison-hackers