On Fri, Feb 12, 2010 at 1:13 AM, Brett Morgan <[email protected]>wrote:
> On Fri, Feb 12, 2010 at 11:53 AM, Turner <[email protected]> wrote: > > > > > > On Feb 7, 7:57 pm, Brett Morgan <[email protected]> wrote: > >> On Mon, Feb 8, 2010 at 10:56 AM, Turner <[email protected]> wrote: > >> > >> > On Feb 4, 3:42 pm, John Barstow <[email protected]> wrote: > >> > > On Thu, Feb 4, 2010 at 1:31 PM, Turner <[email protected]> > wrote: > >> > >> > > > Ah, ok. So the transformer doesn't transform op streams from > different > >> > > > clients so much as it transforms op streams from different > versions. > >> > > > Is that it? > >> > >> > > That's right. From the server side it's [ops the client doesn't know > >> > > about] x [ops the client wants me to apply] > >> > > The version number just tells us which ops the client doesn't know > >> > > about yet (all the newer versions). > >> > >> > > From the client side, it's [ops I haven't sent the server yet] x > [ops > >> > > the server just sent me] > >> > >> > > > And the transformer operates pairwise? So, if there's a stream > with > >> > > > more ops than the other stream, the unmatched ops go through > >> > > > unchanged, correct? And if there's a disparity of more than one > >> > > > between the version numbers, the transformer will need to be > called > >> > > > several times on successive pairs, right? So, for instance, to > bump a > >> > > > client whose last known version is v6 to v8, the server would call > (v6 > >> > > > x v7) x v8. Do I have that right? > >> > >> > > > In the example above, A1' = A1 X B1, B1' = B1 X A1, and so forth, > >> > > > right? > >> > >> > > Well, not quite. Here I think you need to look at the code to get a > >> > > clearer picture, but I'll illustrate in a slightly different way. > >> > >> > > Let's look at the following transform: > >> > >> > > [A1, A2, A3] x [B1, B2] = [A1', A2', A3'], [B1', B2'] > >> > >> > > What we end up with is two sets of operations. > >> > >> > > [A1, A2, A3] + [B1', B2'] <-- Apply the A operations first > >> > > [B1, B2] + [A1', A2', A3'] <-- Apply the B operations first > >> > >> > > (where a + indicates concatenation) > >> > >> > > This implies that transform could be imagined as a sort of matrix > >> > > multiplication. > >> > >> > > A1' = (A1 x B1) x B2 <--- where we just keep the A result of each > >> > transform > >> > > A2' = (A2 x B1) x B2 > >> > > A3' = (A3 x B1) x B2 > >> > >> > > B1' = ((B1 x A1) x A2) x A3 <-- where we just keep the B result of > >> > > each transform > >> > > B2' = ((B2 x A1) x A2) x A3 > >> > >> > > What the transform is doing is asking the question, "What do the A > >> > > operations look like if the B operations were already applied?" This > >> > > is how you get convergence. > >> > >> > > > So, for instance, to bump a > >> > > > client whose last known version is v6 to v8, the server would call > (v6 > >> > > > x v7) x v8. Do I have that right? > >> > >> > > The difference in version numbers just tells the server which > >> > > operations need to be applied to the incoming client operations. > >> > >> > > So if the server is at v8 and the client is at v6, the transform is: > >> > >> > > ([v7] + [v8]) x [client delta] = [results to send client], [v9] > >> > >> > > More concretely, if: > >> > >> > > v7 = [A1,A2] > >> > > v8 = [A3] > >> > > client delta = [B1, b...@v6 > >> > >> > > Then: > >> > > [A1, A2, A3] x [B1, B2] = [A1', A2', A3'], [B1', B2'] > >> > >> > > v9 = [B1', B2'] <-- the A operations were applied first by the > server > >> > > [results to send client] = [A1', A2', A3']...@v9 <-- the B operations > >> > > were applied first by the client > >> > >> > > Does that make it clearer? > >> > >> > Yes, much clearer, thank you. The point about each operation being > >> > composed with each operation of the other stream was a key point. I > >> > was wondering how one could apply the transformed operations to a > >> > client that already had applied the operations that you were > >> > transforming with; now I get it. > >> > >> > So then is it a property of the operations and the transform function > >> > that ((A x B1) x B2) x B3 == A x (B1 x B2 x B3)? I haven't bothered to > >> > work out a formal proof for such an equivalence, but it would seem to > >> > follow from your above explanation. > >> > >> > I have a couple of other unrelated questions that I would love if you > >> > (or anyone else) could answer for me. > >> > >> > 1) The whitepaper mentions "anti-elements". What are those? > >> > >> Anti-elements went away. > > > > Okay, so the whitepaper is just a little out of date? > > Show me an active project, and I'll show you a project with out of > date documentation. > Haha, fair enough. > > >> > 2) The image depicting "positions" in the whitepaper apparently treats > >> > elements (tags) as single entities--i.e., taking up only one position, > >> > like a character. Why is a tag not simply a specific application of > >> > the "insert characters" operation? > >> > >> An issue with collapsing elements is that they become unaddressable. If > i > >> have a series of nested elements that all start after a given character, > and > >> I want to delete a specific nested element, how do I locate it? > > > > I'm not sure I understand the problem. Why not use the position where > > the opening tag starts? > > I suspect I need a whiteboard to explain properly. For a starter, I > said a stack of nested starting tags, so the concept of "the opening > tag" is ambiguous. > Well, the issue to be resolved is, "I want to get to the next <p> tag" (for example), right? I guess I just don't really see the advantage to having a tag take one position (as it does according to the whitepaper) as opposed to it taking, well, more than one position, as it would if it were rendered as a series of insert character ops. > > >> > Thank you once again for all your help. > >> > >> > Turner > >> > >> > -- > >> > You received this message because you are subscribed to the Google > Groups > >> > "Wave Protocol" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]<wave-protocol%[email protected]> > <wave-protocol%2bunsubscr...@goog legroups.com> > >> > . > >> > For more options, visit this group at > >> >http://groups.google.com/group/wave-protocol?hl=en. > >> > >> -- > >> Brett Morganhttp://domesticmouse.livejournal.com/ > > > > -- > > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > > > > > > > -- > Brett Morgan http://domesticmouse.livejournal.com/ > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
