Re: more editor v2

The intent is that the operations are as independent as possible, so that
they could be done in parallel when possible (think: multiple serf
connections).

As you point out, though, certain changes *do* need to be ordered, and to be
applied in that order by the receiver.

Cheers,
-g

On Sep 15, 2009 8:29 AM, "Julian Foad" <julianfoad_at_btopenworld.com> wrote:

Greg Stein wrote:

> Julian Foad wrote: > > This raises a question in my head. In editor v1,
each child node is > > ref...
Yup, I got that.

The thing I was concerned about was whether the editor instructions were
meant to be able to be processed out of order or in parallel. The answer
is basically no. At least the /interpretation/ must be sequential, in
the sense that each path refers to the tree structure left by the
previous instruction (not, for example, the tree structure that existed
at the beginning of the edit), and changes to the same node must be
interpreted in the order in which they were given. Therefore,

 move A to B
 move B to C

moves A to C, rather than moving B to C and A to B at the same time.

There is quite possibly no other sane definition of the ordering of
instructions, but that's what I was wondering about.

On forbidding the driver to issue changes to a node and then delete
it... I agree that there is no good reason to forbid this. In fact, I
can think of an argument for allowing it: I think it would be good if
any two successive editor drives can be combined into a single one
without changing their validity or meaning. So,

 - open_root()
 - blah1...
 - close_edit()
 - open_root()
 - blah2...
 - close_edit()

is defined to be the same as

 - open_root()
 - blah1...
 - blah2...
 - close_edit()

If it were not so, a driver that wanted to do such a sequence could just
accept the cost of having to close the edit and re-open it between each
step, but it would be silly if we enforced that for no good reason.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395225
Received on 2009-09-15 22:01:17 CEST