RE: Standalone xPL Hub Summary

["Ian Lowe" <ian.lowe@xxxxxxxxxxxxxxxxxx>]

As a thought, to avoid the race situation you described altogether (and
hopefully be a little more user friendly into the process)

How about apps *don't* try to bind to 3865 to see if a hub is there -
they don't need to. If we are making a pre-existing hub mandatory for
xPL on a PC, they don't need to check for it's presence.

That means the app can't exit immediately when no hub is there (as it
can't tell) - however, this probably makes it a little more tolerant of
start order. It doesn't really matter which service or app starts first
if none of them even *touch* 3865, and they all just assume that a hub
is present.

Ian.

-----Original Message-----
From: ukha_xpl@xxxxxxx [mailto:ukha_xpl@xxxxxxx] On
Behalf Of Gerry Duprey
Sent: 14 September 2005 17:04
To: ukha_xpl@xxxxxxx
Subject: [ukha_xpl] Standalone xPL Hub Summary

Howdy,

Below is a summary of what I *think* I've been reading on the separate
hub issue.  I've tried to write it as if it could inserted into the
appropriate xPL developer documentation.

Please take a look and lets discuss if this reflects the common thoughts
and correct/alter/etc it so that it does.



Clarifying the role and location of xPL Hubs
============================================

Overview
--------
For network-centric xPL apps (that is, nearly any xPL program that runs
on a
PC), xPL requires a hub to be running.  A hub acts as a single contact
point
for the network and handles dispatching messages to other xPL programs
on a
computer.

Every computer running xPL apps must have a hub on it.  If there is no
hub
or the hub is not running, xPL based applications cannot start.

A hub must be a separate program/task from any xPL based application.
An
xPL application, either directly or via it's framework, should not be
responsible for nor try to start a hub if none is detected.  If the app
were
to take on responsibility for starting/monitoring a hub, the hub becomes

susceptible to that applications lifecycle and health.  Given other xPL
apps
are going to also depend on the hub, such embedding would put xPL on
that
computer in jeopardy should anything happen to the app (or apps) that
are
also trying to manage the hub.

To quote Paul Robinson, "Keep the hub simple and separate".

Hub Author Notes
----------------
Details about the technical aspects of how the hub itself should work
can be
found here <insert link to technical description of a hub>

Hubs should be designed to be as simple and stable as possible.  Failure
of
the hub will result in the all xPL apps running on a computer to be
unable
to hear each other or the rest of the network,  As such the hub program
needs to be written in as "safe" a manor as possible (do all
possible
exception checking, make sure you are using the right APIs in the right
way
and that there are no shortcuts, insure code is written with no
assumptions
and as defensively as possible, etc).

Even the best written programs can (and usually do) have bugs, it's
important that the hub has some separate supervisory process that
insures
the hub is running and when it detects the hub has stopped, restarts the
hub
immediately (optionally logging the problem so that eventually, the
cause of
the failure can be diagnosed).

Ideally, the supervisory role would be played by a standard system
mechanism.  For example, under windows, the hub could be installed as a
service and be set such that the windows service manager will
automatically
restart the hub if it dies.  Under linux, this would have to be done by
an
additional program that launched the hub and then watches it or instead
of a
program, with scripts.  Similar solutions exist in other operating
systems.

When a supervisory program needs to be used (for systems that do not
provide
their own), it's important to keep that program as short and simple as
possible.  For something like unix-y based systems, this could be a
simple
program that just forks off the hub, then waits for the forked process
to
die and forks again (probably 10 lines of C code).

Between a short, simple, stable supervisor and a responsibly written
hub,
there should be sufficient redundancy and failure traps for all but the
most
disastrous cases.

Hub Deployment
--------------
Hubs must not be deployed as part of an xPL application.  If multiple
applications are installed on a computer and each one installs a hub,
chaos
could reign.  And since there are multiple xPL application frameworks,
there
is no good way for them to all agree on a "check and if missing,
install
a
hub" method.

The user of the xPL application should be made aware, in notes about the

application and even on the download page for the application, that an
xPL
hub is required and if they don't have one, they should be provided a
link
to a webpage listing hubs for different platforms (maintained on the xPL

website).

Separate Hub impact on xPL frameworks and applications
------------------------------------------------------
xPL applications and frameworks must not provide any sort of hub
service, at
least not automatically. There can, of course, be code for a hub in a
framework, but it should not be run automatically as any part of normal
xPL
application startup without some special/explicit setting to do so.

Further, if an xPL application/framework starts and cannot see a hub
running
(i.e. the xPL port is free), the application should immediately
terminate.
Depending on the type of application, it should either show an error
message
in a dialog box saying that a hub could not be found and including a
link to
the xPL hubs webpage or, if no GUI is available/appropriate, should
print a
message on the console to the same effect.  If there is an appropriate
system event log for a given O/S, this should be logged there too
(especially if there is no GUI/DialogBox notification possible).

--------------------------------


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



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