RE: Changes to Protocol Docs - a Summary

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

Hi all,

Still catching up on yesterdays mass of emails!

> > If the app is in config mode, presumably when it receives
> > hbeat.request it should respond with a config.app?
>
> The way I've been thinking, I would agree with this (that a
> hbeat.request got a hbeat.app/basic or config.app/basic back
> as a response, depending on the devices state).

Yep - sounds good.

> > Also, to be of any use, the version number would need to be
> added to
> > the config.app schema as well as hbeat.app (or we won't have any
> > version info about programs that are not yet configured).
>
> Related to that, and again, I think this would come as a
> recommendation than a requirement, does anyone have an
> opinion on the format of the version?  I can see 1) Leaving
> it entirely to the developer, 2) suggesting a V1.0 format
> (version=V1.0) or 3) suggesting a "number" only (i.e.
version=1.0)
>
> My thought right now is that the #3 would be the best way.
>
> Note, by "number" only, I mean the raw version ident.  It
> certainly could have letters or something, justs no prefixes
> like "V" or "Vrsn" or anything.

Yes, I agree that option 3 is the best, and it should be a requirement
that if you are going to include a version number, it should be the raw
version number itself, with no prefix etc.

To summarise my own thoughts on recent discussions:

I am quite happy with what is being discussed - the addition of
hbeat.request is a useful way of quickly discovering devices.
Just to clarify though: Version numbers don't go in XML files - they go
in heartbeats.
(I think Mal already pointed this out)

The whole issue around xPLHal, to me, is totally separate, and nothing
really to do with the core protocol.

Although many of us have xPLHal at the heart of our xPL installations,
it is still just an app like any other xPL app - and I don't think it
should become bound up in the core protocol itself.

As for XHCP, again it is related to xPLHal and is purely for
client/server control of xPLHal (which I guess is implied by it's name -
the xPLHal Control Protocol).
It therefore isn't part of the xPL protocol, and shouldn't, at this
stage be relied upon to provide basic protocol-level functionality.

Whether we make xPLHal into a cross-platform environment and integrate
it's functionality tighter into the core xPL protocol, I think is a
discussion we should leave for another day!
(lets get the current protocol changes tested and finalised first!)

Regards,

John