Re: [dispatch] Proposal for Per Resource Events Protocol

[Michael Toomim <[e-mail]>]

Excellent, thank you Dale for these insights!

Dale:
> I don't remember clearly at this point.  Back when I was working on
> Microsoft's "Universal Plug and Play", it did come up that there were
> things people wanted notifications about that were conceptually events,
> not changes in any straightforward "state".  The specific semantics are:
>
> - You are communicating "state" if when there are two updates "state =
>    A" followed by "state = B", it is OK, if the first one is lost as long
>    as the second one is delivered.  (Obviously, this doesn't work if the
>    messages are deltas, but it *does* work if the second message is a
>    "full" update.)
>
> - You are communicating "events" if it is important that *each*
>    notification be delivered.
>
> Of course, you can hack it by saying the state is the cumulative list of
> all events that have happened in the past, but that's not good,
> especially since the "state" grows without bound.

Ah, yes, now I know precisely what you are referring to!

These "events" are semantic labels for transitioning a state machine 
through various states. This is a very common way to implement data 
synchronization across a set of modules, but it has drawbacks:

  * The semantics of the events have to be designed, defined, and
    implemented for each data model that needs synchronization, and each
    module needs to implement them identically. This makes it difficult
    to change the data model, or the vocabulary of change.
  * As you point out, the log of events grows without bound, and if you
    want to compute the current state, you may potentially need the
    entire history.

Both PREP and Braid make it easy to synchronize with state snapshots and 
patches, instead, which makes for a more general & interoperable 
architecture. "Events" can still be included as labels for change, but 
can be optional. You can compute the current state from general 
infrastructure, that knows nothing about the particular data model being 
synchronized.

> My most recent memory is from reviewing
> draft-ietf-i2nsf-nsf-monitoring-data-model-12; it's entirely about
> monitoring, and two sections are "System Events" and "NSF Events".
Good find! This led me to discover NETCONF Event Notifications (rfc5277) 
which is super relevant as well.
> My reflex was to say "Certainly, given the elaborateness of the XML
> system, there must be a way to specify that!", though I know *nothing*
> about XPath.  But searching delivers:
> https://stackoverflow.com/questions/3354987/what-is-the-xpath-to-select-a-range-of-nodes
> "What is the XPath to select a range of nodes?"  So XPath may already
> have all the machinery one could want.  Probably a negative is that the
> straightforward specification would require the subscriber to implement
> all of XPath.

Wow, indeed. Having to specify:

    /bar[position() >= 100 and not(position() > 200)]

Instead of:

    /bar[100:200]

...certainly leaves a lot to be desired. I think we can do better for an 
XML range unit.

Michael