Re: [dispatch] Proposal for Per Resource Events Protocol

[[e-mail]]

Michael Toomim <[e-mail]> writes:
> 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:

I was thinking about this a bit more, and sometimes it's about
synchronizing state across a set of modules, but at other times it's
about "logging", and whoever designed the system doesn't have a clear
concept of state in mind.  One should design in terms of state when
possible, but my experience suggests there are many exceptions.

>> 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.  [...]

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

My memory is that few or none of the SIP event types that support
partial updates consider the state to be divided into a sequence.
Usually, it's a set of key/value pairs, where the key is a string that
identifies the component of the overall state (e.g., the identifier of a
particular call) and the value is some complex structure.  So if you're
considering partial updates, start with having a way to specify
modifying the values for individual keys.  Indeed, you may need little
more than that in practice.

Dale