RE: Configuration Protocol

["Tony Tofts" <tony@xxxxxxxxxx>]

Hi Gerry,

> 1) Locally stored configuration and startup Reading the docs,
> it sounds like if a device can store it's configuration and
> is able to restore that config at startup, the device should
> not go through the normal 'config.app' heartbeat phase and
> just go immediately to hbeat.app "mode" -- is that correct?

Either way is valid. Though going straight to hbeat.app is probably the
better way.

> 2) Locally storing config -- filters and groups too?
> If a device can store it's configuration locally, should it
> be storing the groups and filters for the device too?  Since
> the filters and groups are delivered as part of the
> configuration, I could see this as making sense, but it's
> also seems filters & groups are treated a little differently,
> so I thought I'd ask.

Filters and groups are treated the same.

> 3) When do filters and groups reset?
> If a device received a config.response with configuration
> data in it, it seems clear that any existing configuration
> values should be cleared out first, and then any values found
> in the configuration message installed.  This should happen
> every time a device receives a config.response.
>
> Does this mean that whenever a config.response is received
> for a device, it should also clear out it's filters and group
> settings?  If not, then should the filters and/or groups only
> be reset if a config.response has one or more filter= or group= items?

Filters and groups should always be in the configuration message. But if
none are there this should be considered to mean clearing the list (same as
filter=, or group=, with no value).

> And if that last item is true, should all other configuration
> items be wiped out if a config.response message contains ONLY
> filter= or group= items (i.e.
> no "other" configuration data)?

No, instance name & interval & filter & group are considered
special items
(as they are the only items common to every device/app). An individual
device/app should deal with other missing config items in whatever way is
most appropriate. E.g. if COMPORT= is missing from a config, it would not
be
appropriate to clear the item...

Likewise if a device/app can tell if a value for a given config item is
invalid it should either ignore the item totally or assume a default value.
E.g. volume=999 or -1, when the valid range is 1 to 100, might either leave
volume at it's current value OR set it to a default like 50.

When xplhal sends a config to a device, either automatically or thru user
intervention with the manager, it will then request the current values
back.
Therefore a user can see thru the manager if the values sent have had
effect
or not.

Regards
Tony