xPL Hubs

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

Hi all,

One of the issues to emerge during Tom's recent work on the xPL .NET
library is how we handle the availability of the xPL hub.

The original school of thought was that a hub should be provided as a
stand-alone application, however in reality, apps like xPLHal, xPLRioNet,
and a few others, all ship with hub implementations.

The reason for this is simple: To make life easier for the user.

The new version of the xPL .NET library includes a built-in hub
implementation, and one of the concerns that a number of people (myself
included) raised was that you would never be sure which application was
acting as the hub, and as a result, you could end up with hub availability
problems if you stopped and started apps in a particular order.

Tom and myself have had a number of discussions about this offlist, and we
think we have come up with the best solution from a developer and end-user
perspective.

The upcoming V3 of the .NET xPL library will include a complete xPL hub
implementation, making use of a mutex, and supporting full recovery of
state information.

The xPLListener object will expose a property to the developer to indicate
whether or not xPLLib should try and act as a hub.
By default, this property will be set to True, so every xpllib-based
application will attempt to take on the roll of an xPL hub.

It should be possible for the user to override this setting, either through
a user interface (like the xPLHal Manager in xPLHal's case) or via a
.config XML file.

However, for apps that aren't Windows services, the property should always
be set to false, so xpllib never tries to act as a hub unless it is running
as a service.

Ultimately, the end-user has total control over which app acts as their xPL
hub.
Out of the box, any xpllib-based service can act as a hub, however, if a
user has a particular need for a certain app to act as the hub, they can
easily disable other applications from acting as hubs.

Another advantage of this approach is that it allows us to remove the hub
code from apps like xPLHal and xPLRioNet, meaning we only have a single
.NET hub implementation to maintain and distribute.

The stand-alone hub will continue to be available (purely as a wrapper to
the xpllib-based hub) for those users who either don't have any other xPL
services installed, or for those who still want a specific service to act
as a hub.

We think that this is the best way forward, but we are keen to hear other
people's thoughts on this issue.

Regards,

John