Re: xPL Lib - updates

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

Hi Tom,

> - Added support for a configuration item "listenon": this is
the
> address to listen on for incoming data: valid values are
"ANY_LOCAL"
> or a specific IP.

If xpllib is running as a hub client (i.e. has bound to port 50,000+, it
should only *ever* listen on the loopback address - this ties in with the
hub which should only ever broadcast to the loopback address.

I'd suggest that the value of listenon should only be used if xpllib is not
working as a hub client, i.e. it has bound directly to the base port 3865.
However, I don't know of any apps where it is recommended to bind to the
base port, as you prevent a hub from starting up.
Therefore I can't see where listenon would be useful?

> - Added support for a configuration item "listento": this is
the
> address from which to accept incoming data: valid values
> are "ANY", "ANY_LOCAL" or a specific IP.

Again, when running as a hub client, xpllib should only have bound to the
loopback ddress, so should only ever receive messages from the loopback
address, so again I'm not sure of the use of this parameter.

> - Added comments ;-)

Cool :-)

> It comes down to a rather drastic facelift of the XplListener class.
> With this version you can configure a component's filters via the
> configuration tool (HAL)

Thanks for this - filters are not something that have been used a great
deal, so we haven't tended to concentrate much on this area of the code.

> and the addresses to use for listening on
> and accepting data from.

Can you explain why you feel these would be useful?

> It also allows a developer to define configuration items that can
> have multiple values.  HAL does not seem to like this though...

OK - we can look into what's happening with Hal and get it sorted.

> I stayed as close as possible to the existing interface of
> XplListener (meaning that everything that was declared public is
> still public and has the same type).  Thus developers shouldn't need
> to modify any code if they whish to use this version.

Cool.

> The thing that is NOT compatible anymore is the configuration file
> that xPLLib uses to save and restore state.

OK - what happens if a new release of xpllib comes across an existing XML
config file?
How much of it can it read, or does it ignore the whole thing and come up
as a new instance?

> Is there a well-defined way for co-operation, code distribution and
> version control ?  I think that the easiest is that I forward the
> code to the original developer of xPL Lib and let him decide what to
> do with it ?  Can that developer please raise his hand ?  Anybody
> volunteering for beta-testing ?

That'll be me then :-)

If you send me the code offlist, I'll take a look at it and have a go at
integrating it into some of my apps and see how we get on.

Regards,

John