Changes to Protocol Docs - a Summary

["Ian Lowe" <ian.lowe@xxxxxxxxxxxxxxxxxx>]

This is an attempt to summarise the discussions of the last few days -
if I have misstated anything, please feel free to post a correction. I
have also dug out a couple of back thoughts from previous discussions we
have had that didn't come to anything.

For the record, I am in agreement with everything stated in this email.

===============================================================
1) Discovery mechanism

It is proposed to add an additional extension of the hbeat.app schema,
hbeat.request.

The hbeat.basic schema will remain unchanged, and is intended as the
simplest heartbeat protocol for devices/standalone apps. hbeat.basic
remains "one way".

hbeat.app will be extended to include hbeat.request - this xpl-cmnd
message, when received by an application, will cause the application to
send a standard heartbeat message.

To avoid the possibility of network congestion, hbeat.request should not
be issued more than once in a 30 second period.

===============================================================
2) Rapid Startup

When an application using hbeat.app starts, it will send heartbeat
messages at a faster rate of 1 per 3 second interval.

When the app recieves it's heartbeat back (indicating that it has
succesfully joined the xPL network) this will drop to the normal
heartbeat rate (as specified in the hbeat.app message's
"interval"
field)

If no succesfull heartbeat has been received (ie, a fault condition
exists, such as no hub present) the heartbeat rate will drop to a lower
rate of 1 per 30 second interval after an initial 90 seconds.


===============================================================
3) Device Information

It is proposed that the production of an xml fragment describing a
vendor's applications is now a required condition of being assigned a
vendor ID. The XML fragment should describe the various triggers and
commands that are provided by, or accepted by the applications.

This fragment should contain information for each version of an
application, where functionality has changed between versions.

To support the use of this information, all heartbeat messages
(hbeat.basic as well as hbeat.app) should be amended to include a
"version=" tag. Version numbers should contain only numbers and
the
decimal point character "."

===============================================================
4) Extended Heartbeat information

Applications using the hbeat.app heartbeat schema may, at the developers
option, include additional information tags within the heartbeat
message. This is supported by the protocol at present, however, where
this information is provided it *must* be described within the vendor's
xml fragment so that this extended information is available to all
management apps within the xPL network.

===============================================================
5) Case of xPL Message elements

It is proposed that the xPL protocol document be amended to reflect
common usage - it has been stated on several ocassions that structural
elements of xPL messages (anything within the header and all
"name="
elements) should be in lower case only.

At present, this is enforced within the various development frameworks
but not explicitly stated within the Protocl document.

===============================================================

How's that for a draft?

Ian.