Re: [dispatch] Proposal for Per Resource Events Protocol

[[e-mail]]

Michael Toomim <[e-mail]> writes:
>> One thing I've noticed with subscribe/notify mechanisms is that the
>> initial definition tends to be oriented toward sending "status"
>> messages, that is, each notification is the current status of the
>> resource being watched.
>
> By "status" do you mean the current "state"?

Yes.  Sorry, sloppy editing on my part.

> If my resource is a text document, do you mean sending the entire string 
> of the document each time the user types a char?

I've never seen an application that was monitoring what was conceptually
as "document" as a user would use the term.  But I do mean "this is a
change in a state, and the change is a lot smaller than the whole
state".  IIRC, that was my point "1".

>> (2) Often the desired semantics isn't to communicate current state but
>> to communicate that an (instantaneous) event has happened.

> Can you give some examples of events that you've encountered that do not 
> imply a change to the state? I usually find that events /are/ 
> communicating changes to state, even though it might not be obvious what 
> the state is.

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.

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".

>>> We call this format the Range Patch
>> You probably want to add an "XML" type of range specification, given the
>> amount of XML that is used to deliver state information.  (Certainly,
>> it's popular in SIP.)
>
> Yes! Definitely.
>
> XPath could be a starting point, but we'd ideally want something that 
> also allows to specify a range of children, and not just a single child. 
> It's nice to be able to say that children 4 through 10 got replaced, 
> rather than have to issue 6 separate patches, with one for each child.

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.

Dale