Re: xPL Hubs

["David Amphlett" <dave_yahoo@xxxxxxxxxxxx>]

quick disclaimer - new here (been lurking) - haven't really
introduced myself yet (I'm Dave - met a few of you at UKHA2004) -
haven't contributed anything yet, but am working on a couple of
(potentially commercial) projects that will hopefully include an xPL
component

One of the things I'm looking at right now is a seriously beefed up
Hub - the beefing isn't w.r.t. xPL (as that whole side of things is
pretty straight forward), but instead more interms of reporting and
control, so I'm looking for instance as syslog, snmp, a webservice
for statistics reporting and control etc.

Now I'm focusing on linux for the minute (and Gerry's xpl4Java's
going to make me a very happy bunny), but am also seeing the
potential of reporting to perfmon and the possibility of implimenting
an mmc for a hub.

I'd had to go to all that trouble to make a super duper easily
managed hub only to have an app install itself and grab the port
before my hub gets a chance - so

I'd hope that the user will always get the chance to ensure that they
can enforce which hub to use in a deterministic manner (without
having to know what's happening under the hood).

I guess I'd view a hub in the same was as a web server. The user
wants one, but doesn't care which - until they download and install
one for a particular reason (like they paid for it) - then, that's
the one they want.

webservers usually standalone. If an app includes its own it might
check to see if one's already running *** during installation *** and
offers it's own if it can't find one, or maybe it's an option within
the program - but it wouldn't check everytime it runs or apache
wouldn't ever get a look in.

Or maybe a standalone hub should offer an mpeg player style - I'm not
your default hub right now - would you like me to be? option - but
then how does it tell all of the other possible hubs to go away.

But hey - surely it's easy to embed an installation of a program to
install a standard standalone hub - just as easy as embedding one in
a program?

anyway, enough of my ranting - I support the idea of default false
for magic library hub invocation, and think we should suggest a
requirement of apps that include library hub so that they can be
switched off in a reasonably standard manner.


--- In ukha_xpl@xxxxxxx, "John B" <home-automation@j...>
wrote:
> 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