Re: Changes to Protocol Docs - a Summary

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

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

A lot of this is really in the optional category for exactly the reasons
you
enumerate -- it adds complication to devices that may not be able to handle
it.

1) device discovery.  I think that we can work a device discovery protocol
out that reuses most of the devices existing logic for sending heartbeats
(if it has them).  It should be reasonably easy to fit it in (I did a test
last night by adding support for it in one of my PIC based devices and it
added 25 bytes to the ROM and no additional RAM).

And if the device cannot do it, it does not have to.  It adds a great deal
of power to the network and particular types of front ends, but I don't
think it can be made mandatory because of the range of xPL implementers.

And I've said pretty much exactly what you expressed -- if we set the bar
too high, developers may just skip trying to implement things.  If we reuse
common idioms that are already out there with minimal new stuff, it should
be easy enough most developers won't feel too much pain to do the change.

2) rapid startup.  Again, this was done is a way that is pretty easy to
implement with existing heartbeat code.  If you are already sending a
heartbeat and listening, adding logic to do this isn't much.  However, I
suspect most small devices do not have to deal with a hub and therefore,
they do not (and should not) implement rapid startup (it really is only for
hub discovery).  So in most cases with embedded devices, they;ll be NO
change in RAM/ROM space or code.

3) Device information.  Fortunately, being entirely exterior, this has
absolutely NO impact on a device.  It would be up to the developer to
create
a XML file, but that file does not have to be packaged inside the device (a
separate, downloadable file is all that is needed).  No change in RAM/ROM
space or code.

4) Extended heartbeat info.  This is optional and in most cases, for
embedded devices, will not have to be done (unless you, as a developer,
have
something you do want to share this way).  So in most cases, it has NO
impact (no change in RAM/ROM space or code)

5) Case of message elements.  Again, upper vs. lower case will not require
any additional code/resources in a device (other than changing it to send
lower case if it sends upper or mixed case now).  No change in RAM/ROM
space
or code.

Gerry

--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org