Julian raised a question when I saw him in September: how does Ev2
deal with a node swap? ie. swap the contents of A and B, retaining
metadata that they were moves [rather than copies from history].
In Ev2, we attempt to disallow "mv A B ; mv B C". The semantics around
the interface say you should just do "mv A C".
But to accomplish an A/B swap, you must "mv A temp; mv B A; mv temp
B". Thus, A -> temp -> B, which is nominally disallowed in the Ev2
interface.
Question: how to resolve this, given that we're starting to record
*move* information? (the current interface could do: mv(replacing) A
B; copy B_at_REV A)
I've been thinking about a "multiple move" API to describe these kinds
of changes. It isn't just a simple swap, since you could rotate
content through an arbitrary set of N nodes. Suppose we had an
interface that specified N nodes, and node[i] is moved to node[i+1],
with the last one moving to node[0]. Would this be sufficient? I
suspect that any moves *outside* of this ring uses the standard
interface -- it is not participating in the rotation. Hrm. Maybe the
API is named "rotate" rather than multiple move. (I say rotate because
I'm envisioning the larger case where you have (say) 5 nodes, and each
piece of content rotating to the next; looks like a clock or musical
chairs)
I'm not a master of topography or graphs, but I suspect that any given
permutation of N nodes can be reduced to a set of rotations of subsets
of those N nodes. Thus, a general "rotate" API should be sufficient.
Cheers,
-g
ps. there is a corollary, unstated question of whether these kinds of
rotations/multiple-move can be recorded in our WC schema.
Received on 2011-11-06 01:21:37 CET