Re: Targetted events

[Stuart Booth <lists@xxxxxxxxxxxxxxxx>]

On Sat, 19 Jun 2004 12:10:19 +0000, mcs101main@xxxxxxx wrote:

>It seems like the Q1 & q2 questions posed are out of some centext
that I have not been tracking, but I'll throw in my view.

It's fairly general in that it can apply to a change of state on a
Transport e.g. Play on some MP3 receiver perhaps, or ON to some kind
of switch. Or in my case a change to a variable in the RR, or even to
the enablement state of its IR detector.

Kevin asked elsewhere what should occur if an event message should be
sent if a change of state was requested, even if the device was
already in that state. Should it send a .Info message or a .Event
message.

I've just arrived at a similar thought whilst tidying up the RR
Connector and want to do The Right Thing.

>If the content of the message means something different to different
nodes then the message should have a target address.
> If the content of the message means the same to all nodes then no
target address is used.

I'd agree with that. A query is a response to a particular node. A
command that (maybe) changes state and generates an event is of
interest to all, regardless of a response target.

>A node that supports events has a list of events that it will generate
based upon some criteria.
>If the receipt of a message does not trigger one of these criteria then
an event message should not be sent.
>
>The content of an event messages needs to adhere to the
optional/required key specification of the schema,
>but in general I would think that only the key that has changed would
be reported as an event.
>The status of all keys would be reported as an Info message.

So send a .Event message detailing exactly what has changed, and a
.Info as a compound statement of all that is known.

This might result in an empty message (but presumably not invalid in
the context of a .Event section of the schema) if nothing actually
changes, but it does provide confirmation that the original request
was at least acted upon. However the empty message is redundant.

>If the original sending node is expecting an event change and the
message that it sent did not result in one
>then we have situation of a design fault or a communication fault.  If
it is important to the sending node
>that he receives a message acknowledge then he needs to send a query
message to confirm.

Kevin previously wrote some words with a good description of this
problem. I hope he won't mind me copying a chunk from it!

66
I want a setup such that I turn the stairway lamps on and then 5
minutes later I turn them off unless something else has turned them on
inbetween. Now I can't easily tell if something else turned them on if
they didn't issue an event message to tell me this (as they didn't
change state :-(
99

S
--
Stuart Booth <stuart@xxxxxxx>
xAPFramework.NET - a xAP software development framework for .NET

http://www.xapautomation.org/ 
     http://www.xapframework.net/