xPLLib v3.0 Public Beta

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

Hi all,

Over the last couple of weeks, Tom Van den Panhuyzen has been working hard
on the next major release of the xPL
.NET library (xpllib).
This is the core code behind many of the .NET applications that are in wide
circulation, including
xPLHal, xPLRioNet, and many more.

Tom has been concentrating on enhancing the internal workings of the code,
as well as adding some extra features.

A beta of xPLLib v3.0 is now available from http://www.xpl.myby.co.uk/info/xpllib/
The file changes.txt that is included in the beta download explains in
detail the changes between the 2.x and 3.x versions, however I will
summarise some of the major changes below, as I think some of them deserve
some discussion here.

Note: This beta is only of use to you if you are a developer. You cannot
just download the new xpllib.dll and drop it into your apps without
recompiling.

** Built in xPL Hub **

xPLLib now includes the ability to act as a hub client.
This means that apps like xPLHal do not need to implement their own hubs,
and avoids the potential problem of keeping
various hub implementations in sync with each other.

This also means that any app that uses xPLLib can act as a hub, without the
developer needing to write any code.
Traditionally, we have had concerns over such an architecture, because if
the app that is acting as the hub were to fail, other xPL apps on the PC
would stop hearing xPL traffic until at least one heartbeat interval had
elapsed.

xPLLib v3.0 overcomes this problem by using a mutex to determine whether a
hub is active. This means that if the app that is running as the hub were
to fail, another app can instantly recognise this and take over.

The only time things get complicated is when you consider hubs that are not
build using xPLLIb, and hence cannot make use of the xPLLib mutex.

I guess the question is: Do we want any app to be able to act as a hub, or
are we happy with the present situation where the user specifically
designates an application to act as the hub.
It has always been the view of the xPL team that there should be only one
app that can act as a hub on a computer at once, so that
end-users receive consistent results.
What are people's views on this?

** Security **

At present, apps built with xPLLib v2.x will, by default, listen on all IP
addresses, and accept traffic from any source.
For those who have unprotected Internet connections, this could be a
security risk, particularly as xPL becomes more well-known to the Internet
community at large.

In V3.0 of xPLLib, only xPL traffic originating from the local computer
will be accepted, unless the end-user specifically enables reception of
traffic from the network. The idea here is to adopt more of a "secure
by default" approach, and only open up network traffic for those users
who need it, and know how to configure their firewall accordingly.

A small GUI utility will be available for users to specify their xPL
network settings - this can be downloaded as a stand-alone app, and will
also be integrated into the next release of xPLHal Manager.

The question is: Do we go for "secure by default", and ask users
to specifically enable reception of xPL messages from their network, or do
we stick with the present approach where it all works out of the box, but
you are expected to have a firewall.

My own view (and I think this differs from Tom) is that it should continue
to accept traffic from the network by default.
Ethernet is after all the main transport mechanism used by xPL, and forcing
users to specifically enable support for receiving xPL messages over their
network seems like a step too far to me.
If you have an Internet connection, you should run a firewall that blocks
every port by default, and
only opens up the ones you have specifically chosen to allow through.

xPL-over-Ethernet is a broadcast protocol - it is insecure, unencrypted,
and was never intended for hostile environments like the Internet.
For this reason it should be up to users to protect their networks with a
firewall, and not up to xPL to offer that protection.

If you disagree with this view, please let me know - I'll go with the
majority vote on this one.

** Other changes **

There are some other changes, like proper support for multi-value config
items, and a number of bug fixes.
These are all detailed in the changes.txt file that accompanies the
download.

If you are a developer who has used xPLLib in the past, please take a look
at the v3.0 beta and
let us have your thoughts.

Regards,

John