Re: xPL Hubs

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

One problem I can see with using the mutex approach is integration with
other
non-.NET (or non-native) apps.  For example, if there is a Java based app
running on the same machine as one hosting some of the .NET derived apps,
the
Java app cannot participate in using the mutex.

xPL4Java also includes a built in hub that can either be explicitly
demanded
(i.e. the developer asks the hub to start) or can auto-start (the hub
attempts
to figure out if there is a hub already running on the machine and if not,
will start one).  It does this by checking the ability to bind to the
XPL_PORT.  If it can bind, the assumption is there is no hub running.  If
it
cannot, then a hub (or something pretending it's a hub) is running.  The
nice
thing about this is it works on any platform/language.

xPL is great in that, at a protocol level, it makes no assumptions about
the
hardware it's running under.  While there has been a very respectable
amount
of Windows-specific xPL development, in xPLs platform agnostic spirit, I
think
it would be of value to consider a solution that 1) allows multiple
development platforms to run and cooperate and 2) that is general enough
that
it can be used as a model for how to negotiate the hubs on other
non-windows
platforms too.

Gerry


John B 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
>
>
>
>
> xPL Links: http://www.xplproject.org.uk http://www.xplhal.com http://www.xpl.myby.co.uk
> To Post a Message: ukha_xpl@xxxxxxx
> To Subscribe:  ukha_xpl-subscribe@xxxxxxx
> To Unsubscribe:  ukha_xpl-unsubscribe@xxxxxxx
> Yahoo! Groups Links
>
>
>
>
>
>

--
Gerry Duprey
Ann Arbor, MI 48103
http://www.cdp1802.org