Branko Čibej wrote: On 14 Aug 2013 16:23, "Julian Foad" <julianf...@btopenworld.com> wrote: >> > and also makes validating the drive easier. >> >> I'm not sure what you're thinking about validating the editor drive being >> easier. > > Move away without a matching moved here (or the converse) is clearly invalid. > It must be trivial for the receiver to detect that. Making the temporary > locations explicit makes that so much easier.
It does? I don't see how. You're saying that keeping track of whether there are mismatches in a sequence such as this (which swaps siblings A and B): - move(A,tmp1) - move(B,A) - move(tmp1,B) is so much easier than with a corresponding non-explicit sequence which could be - move(A,tmp1) - move(B,tmp2) - move(tmp2,A) - move(tmp1,B) or - move(A,tmp1) - move(B,tmp2) - move(tmp1,B) - move(tmp2,A) ? Assuming an implementation whereby the receiver keep a list of nodes that are currently in temporary storage, I can see that the list will be shorter with the former protocol, and have fewer insertions and deletions, but that's all. > Regarding direct move without intermediate state, IMO the driver should be > required to to use that whenever it can. That would necessitate us defining "whenever it can" algorithmically. For example, calculating the minimum possible number of direct moves required to perform a given set of moves. That seems difficult. Granted the Ev2 design philosophy includes being minimal (no duplications) in general... but I just don't see this particular rule being easy to codify. Perhaps we can do it. > Driver always has enough info to know that receiver can process such a move. > If > it cannot, that indicates a bug in the driver. Yup, agreed there. - Julian