Re: Targetted events

[mcs101main@xxxxxxx]

--NextPart_Webmail_9m3u9jl4l_13451_1087647019_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

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.

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.

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.

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.


-------------- Original message from Stuart Booth : -------------- I've
just been tidying up and updating the RR Connector when I came
across some scenarios similar to ones Kevin has mentioned wrt BSC.

If I sent a targetted message that changes the RR location
name/description (a featurette of the RR SDK), I want to send out an
event message indicating it has changed. So it's a fairly generic
problem to have.

Q1: should this event be targetted back at the originator of the
change request, or a more general broadcast?

Q2: if nothing has actually changed should I munch the original change
request, or just act upon it as if it actually HAD changed something?

As far as Q1 goes, I'm tending towards a targetted response unless it
changes locally e.g. inside the Connector, in which case a general
broadcast is appropriate.

I am also wondering what to do about the case where something
partially changes. Maybe there are 2 parameters being assigned, but
only one of these actually makes a change. A .Event message might
include just those parts that have changed. But if nothing changes
we're back to absorbing the change request and not acting on it. The
sender has no way of knowing it was acted upon, even if nothing
changed.

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

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