Re: [dispatch] A State Synchronization Working Group

[Michael Toomim <[e-mail]>]

Thanks, Dale! This is a great prompt/question.

Dale R. Worley wrote:
> The state synchronization application I'm most familiar with is the SIP
> event notification model.  It is a framework and a number of different
> types of events are defined within the model.  The interesting event
> types have a state which is expressed in XML but is logically a set of
> name/value pairs (sometimes the values themselves are composed of
> name/value pairs) with each event type defining ways for the event
> notifier to send partial and full updates to the state.  Within those
> systems, an operation "replace range X with contents Y" is not so
> useful, as that operation implies a state structure which is a long
> ordered sequence of small data items.

The Braid model actually works great for SIP.

The "range replace" operations do not imply "a long ordered sequence" as 
you presume.  The "range" part is very general — it can express a "name" 
in a name/value pair, or a GraphQL query, or even a SQL query.

For example, let's say we want to update the presence of this SIP 
participant, expressed as PIDF:

    <?xml version="1.0" encoding="UTF-8"?> <impp:presence
    xmlns:impp="urn:ietf:params:xml:ns:pidf"
    xmlns:myex="http://id.mycompany.com/presence/"
    entity="pres:[e-mail]"> <impp:tuple id="tj25ds">
    <impp:status> <impp:basic>open</impp:basic> </impp:status>
    <myex:complexExtension> <myex:ex1
    impp:mustUnderstand="1">val1</myex:ex1> <myex:ex2>val2</myex:ex2>
    </myex:complexExtension> <impp:contact
    priority="0.725">tel:[phone]</impp:contact> </impp:tuple>
    <myex:mytag>My extended presentity information</myex:mytag>
    </impp:presence>

We could update the status from "open" to "closed" with a Braid message 
like this:

    Content-Range: xpath
    //impp:presence/impp:tuple/impp:status/impp:basic/text()
    Content-Length: 5

    closed

In this case, we're saying that the *range* of the PIDF XML, as 
expressed via an *xpath*, has been replaced with the new value "closed".

A big advantage of this general mutation format is that we don't have to 
specify separately every event type for every type of mutation that 
might occur. We just have to specify the format of the data that we are 
synchronizing (e.g. the PIDF specification) and then use general 
mutations to express which parts of that format are changing.

This simplifies the synchronization specifications, and allows us to 
build general-purpose synchronization infrastructure. For example, 
rather than writing code to synchronize presence info, we can re-use a 
XML synchronizer. And it actually turns out that XML synchronizers can 
share a lot of their code with JSON synchronizers, DOM synchronizers, 
and so on!

Michael