On Mon, Feb 15, 2010 at 2:53 AM, Turner Hayes <[email protected]> wrote:
>
>
> On Sun, Feb 14, 2010 at 3:40 AM, Christian Ohler <[email protected]> wrote:
>>
>> On Sun, Feb 14, 2010 at 3:18 AM, Torben Weis <[email protected]>
>> wrote:
>> > However, it is a pity that the spec is not edited in a wiki-style,
>> > because
>> > the contribution model does not lend itself to community contributions.
>> > As a
>> > result, the comments made on this list and the errors+solutions detected
>> > while implementing the spec are likely not to find their way in the
>> > specs
>> > and whitepapers.
>>
>> The federation protocol draft spec has been in the repository at
>> code.google.com for a long time, and the whitepapers have also moved
>> there recently, e.g.
>>
>>
>> http://code.google.com/p/wave-protocol/source/browse/#hg/whitepapers/operational-transform
>>
>> The barrier for contributing to this is higher than it would be with a
>> wiki; but for specifications and similar documents, this is probably a
>> good thing.  Please send your contributions through the usual code
>> review channels.  We would like to see the errors that you found
>> fixed.
>>
>> Oh, and "retain" is not an operation, it's an operation component :)
>
> What's the difference between an "operation" and an "operation component"?

An operation consists of operation components. In the simple case of
using Wave's OT to munge just straight text, the components that
matter are characters, deleteCharacters, and retain. Maybe some code
will help illuminate?

Let's say we start with a ten character document, and we want an
operation that deletes two characters at position 2, and adds four
characters at position six. Here is the code to do that, using Wave's
OT.

public class OpsVsOpComponents {

        public static void main(String args[]) throws OperationException {

                // A ten character document
                BufferedDocInitialization document = new
DocInitializationBuilder().characters("1234567890").build();

                // Dump the current document
                dump("document", document);

                // An operation to delete two characters at position two and 
add four
                // characters at position six.
                BufferedDocOp docOp = new
DocOpBuilder().retain(2).deleteCharacters("34").retain(2).characters("abcd").retain(4).build();

                // Dump the operation
                dump("docOp", docOp);

                // Apply the operation to the document
                document = 
DocOpUtil.asInitialization(Composer.compose(document, docOp));
                dump("updated document", document);
        }

        private static void dump(String context, DocOp docOp) {
                System.out.println(context + ": " + 
DocOpUtil.toConciseString(docOp));
        }

}

The output looks like the following:

document: ++"1234567890";
docOp: __2; --"34"; __2; ++"abcd"; __4;
updated document: ++"1256abcd7890";


>> Specifying an absolute position/range for each component would indeed
>> be an alternative.  The way we defined our operation components forces
>> each operation to traverse the document exactly once, from left to
>> right, which leads to more efficient algorithms for transform and
>> compose.
>
> Hmmm...yes, I see. But then I'm a little perplexed about how the transform
> is supposed to be implemented. For example, let's say we have an insert op
> that begins at position 6. We need to compose it with a delete chars op that
> begins at position 3 and deletes 2 chars (or, more accurately, 2 positions).
> With an absolute position specified as a property of the operation, it's a
> trivial task to transform that--we just decrement the insert op's position
> by 2 (the length of the delete). But if we manage offsets using the retain
> op, then wouldn't we need to have some awareness of what comes before the op
> we are transforming (e.g. "to transform this insert op on this delete op,
> step back through the operations before the insert op and reduce a retain
> op's range by the delete length")? Or is there a cleverer way to do this?

org.waveprotocol.wave.model.document.operation.algorithm.Transformer
is a fun read.

>> Hope this helps,
>> Christian.
>>
>> --
>> 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.
>>
>
> --
> 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.
>



-- 
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].
For more options, visit this group at 
http://groups.google.com/group/wave-protocol?hl=en.

Reply via email to