Re: Changes to Protocol Docs - a Summary

[Mal Lansell <mal@xxxxxxxxxxx>]

Ian Lowe wrote:

>
>
> 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.
>
Here's a question - when you send that "on demand" heartbeat, do
you
reset the counter for the next timed one, or does that get sent at the
same time as it would have anyway?

> 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! ;)
>
That's too bad.  Whatever your next venture, I hope it works out for
you.  In the meantime, get coding dammit!! ;-)

> > 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.
>
Version number is not a requirement - it's just an aid to the end user.

> > 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.
>
So do you think my hub should lower-case all the messages that pass
through it (it's actually simpler to do this)?

Mal