Re: Hub Operations

["David Buckley" <db@xxxxxxxxxxx>]

--- In xAP_developer@xxxxxxx, "Michael McSharry"
<mcs101main@a...> wrote:
> MessagePort 3639 is someting that needs to be managed and if
> an application claims responsibility for it, then I thing it
> also needs to take-on the role of hub function.

There is a problem here.  Currently it is not the case that all
applications have inbuilt hubs, and although I hear where you are
coming from, I dont agree that it should be the case.

The current problem is that when a non-hub capable application takes
port 3639, a second application can come along, find 3639 busy, and
ASSUME that 3639 has a hub has bound to it, and then starts the
dynamic port charade.  In reality there is no hub, and thus the second
application is deaf.

There is the folow-up problem that if an application that is acting as
the hub either fails or is closed, then the system's hub has vanished,
and any other applications are now deaf, and wont know it.

This goes right back to installability and usability for non-experts.

Therefore, one of several things needs to be done.

a) Nothing, everything is fine as it stands.

b) Every application must be hub capable, which then means we have a
plethora of applications most of which have real-world-untested hubs
in them.  This still doesnt solve the "vanishing hub" problem.

b1) A series of platform specific "hub" components built that are
of
compact size (ie for Windows doesnt require MS .Net framework and
xFx), and free from commercial use restrictions, and are thouroughly
tested, and it is recommended in the strongest terms that all
applications use them.  This still doesnt solve the "vanishing
hub"
problem.

c) Hubs are mandatory, and applications dont attempt to bind to 3639.
For reliable operation, a mechanism to detect the presence is
required, as well as a solution to the vanishing hub problem.