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

Reply via email to