RE: Changes to Protocol Docs - a Summary

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

> Can I just check which parts of this are going to be mandatory and
which optional.

Actually, Gerry's post does a pretty good job of summarising the stuff,
but I'll add my own thinking at this point.

> I haven't followed the whole thread but with each added piece of
protocol it makes it
> more and more difficult to fit this type of logic into an embedded
device.
> The original aim of xPL was to make it simple enough that end products
could talk
> native xPL but it looks like we are going more down the road of PC
side gateway
> apps with all the added functionality being thrown in.

It's one of the reasons I posted this as a summary - I got the distinct
impression that this sounded like creeping complexity (which may be one
of the reasons Tony took the decision to step back from the project).

When you put it all together, and without the discussion back and forth,
there's very little actual work to be done - the changes are small, and
I am now convinced that the benefits to be gained by doing so are quite
dramatic.

> 1) Discovery mechanism
>
> It is proposed to add an additional extension of the hbeat.app schema,

> hbeat.request.

Hbeat.basic stays the same, so small device complexity is untouched -
only PC apps will notice the difference, and even then - it's a
framework change, then a recompile.

To the frameworks (xpllib, xpl OCX and xpl4Java) it means adding the
"if
this message is hbeat.request, send a heartbeat now." logic.

We then recompile, and bob's your auntie :D

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

Again, this is easy - I have Tony's OCX source code here, I reckon I can
add both the hbeat.request and rapid startup to it easily. From there,
it's just a recompile of the apps.

Tony has given me his blessing to work with the source of his apps, and
mirror them on the  xplproject.org.uk website. I am hoping he'll come
back to the project after a wee break, but in the meantime, nothing
that's already in existance will be lost.

Given that my business went into liquidation last week, I have plenty of
time to get things working! ;)

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

...and this isn't really a change at all, it's just formalising the
situation.

There's a *tiny* impact on small devices, in that a version number needs
to be added to the outbound heartbeat messages, but that's easy enough.

> 4) Extended Heartbeat information
>
> Applications using the hbeat.app heartbeat schema may, at the
> developers option, include additional information tags within the

This is an option, not mandatory, and is for hbeat.app, rather than
hbeat.basic.

> 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


This is the change we discussed back in November last year - this will
make the life of PIC and AVR based devices *much* simpler, as they won't
need to handle "MiXeD CaSe" message elements - it's already
present in
the OCX (just checked the code) and adding it to xpllib and xpl4java
shouldn't be too hard.

Has this eased your concerns Steve?

Ian.