Re: [dispatch] A State Synchronization Working Group

[[e-mail]]

Michael Toomim <[e-mail]> writes:
> *1. Ready for Standardization*
>
> These four aspects are currently specified in 
> draft-toomim-httpbis-braid-http [1], and are ready for standardization:
>
>  1. General History & Versioning
>  2. General Subscription & Update semantics
>  3. General Mutation Language—for the class of "replace range X with
>     contents Y" operations
>  4. General Merging & Consistency specification semantics
>
> I claim that anything you want to do with history, mutations, 
> subscriptions, or merging can be done in the Braid-HTTP abstract model. 
> Our group has deliberated, specified, implemented, and tested this 
> against multiple concrete systems. For instance:

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.

Dale