Re: Format of xap packet

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Hi Dave,

I think the main purpose of including multiple bodies is to tie the
context of the blocks together and to ensure everything within one
message is processed . That's not to say that this always happens but if
it isn't necessary then the blocks could have been originated as
separate messages.    The context could be important in that the
information in one block , for example say a list of temperatures (min
max average) could only be valid in the 'context' of the other block
which might have some data relating to measured  time periods or
something. Perhaps the same could happen with TV listings (I haven't
looked at that schema) with recording information related to program
descriptions/schedules in another block perhaps. I'm thinking this is
probably a bad way to design a schema with this contextual relationship
between blocks but it surely happens.  If you effectively break the
blocks back out into separate messages you would lose this.

In typical usages the purpose is very much to cause the blocks to be
processed as one message, for example using the BSC 1.3 schema..  Here
is a 'cmd' message (from the BSC spec doc) that turns one device ON and
another OFF . The idea here is to process the message as one such that
the changes are always synchronised, ideally the state changes within
the device should be coincident. Certainly there should never be the
possibility that only one of the state changes happens.

{
v=12
hop=1
uid=FF123400
class=xAPBSC.cmd
source=ACME.Controller.Central
target=ACME.Lighting.apartment:>
}
output.state.1
{
ID=03
State=ON
Level=50%
}
output.state.2
{
ID=1B
State=OFF
}

Having said that I suspect that most people would still process this
sequentially/as two messages , changing the '03' output to ON followed
immediately by changing the '1B' output to OFF. The key aspect is that
both changes happen, or neither (should the packet not be received). If
the device does support a mechanism for presetting it's outputs , say
with a latch, and then actioning all changes coincidentally then
technically that would be the correct way. Then there couldn't be a
glitch time during which both could be ON for example.

One thing that you will read in the xAP v1.2 spec is that it is
allowable to include within each body a target= line which effectively
combines with the main message target= line in teh header to further
restrict which devices action each individual body part. Often the
target in the header would have some wildcard construct and the one
within the body would be more focussed, but could again use wildcards.
Although powerful this in practice is complex to implement and has
limited application , indeed as far as I'm aware no-one has used that
feature . As such it is proposed in the xAP v1.3 specification that it
be deprecated - which you'll be pleased to hear.

Kevin






drodegeb wrote:
> I am developing a DLL in vb.net to be used in a couple of my future
> projects.  I am hoping to have this dll do most of the work and make
> it simple to integrate into other applications.  I understand that the
> packet can have multiple bodies.  Is it likely that the bodies are
> actually tied to each other and need to be processed together, or just
> based on the same header?
>
> The reason is that I want to pass the messages to the primary
> application calling the DLL, and I don't mind repeating the header
> over for each part of the body to make it easier in the parent
> application.
>
> Thanks,
>
> Dave Rodegeb
>
>
>
>
>
>