Standalone xPL Hub Summary

[Gerry Duprey <gerry@xxxxxxxxxxx>]

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