RE: xPL-Issue

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

>Consider you start an app (like xPLHALMgr) that starts a hub,then you
>run another xPL app that sees there is a hub and uses it, then for
>some reason later, you stop xPLHALMgr and the hub is gone.  The other
>xPL app is left high and dry with no hub.

One question - does xPlHal's monitor have the v3 hub functionality
enabled? If so, then add it to the list of software exhibiting the issue
- I have quite often found that the manager monitor doesn't capture any
packets, even when other xpl apps on the machine are working fine - I
just put it down to NT4 quirkiness, but on reflection, it's the same
fault that we see with xplhal itself - basically not forwarding the
packets, but not complaining either.

> Yeah - I know.  I really don't have a perfect answer here, but we do
have a problem to
> iron out and really, because it's integral to the xPL protocol, we
probably need to
> figure out a cross platform solution so all xPL apps can either be
responsible for
> launching the hub as needed and keeping it running or require some
other way to have a
> hub.  Clearly, a computer running an xPL app needs an xPLHub.

I agree - there doesn't seem to be a "perfect" solution here, and
the
ability to run a mixed environment without any issues only complicates
things further - what's different between John's environment and Franks?
or mine?

> Given the above dialog, I'm thinking the hub itself and/or some
control structure around > it should be responsible for starting it and
restarting it as needed.  I suspect that a > service (under windows)
would handle that (restart on failure -- not sure as I'm really > not a
windows guy). Such a thing would be pretty easy to do on
> linux/unix/OSX/Solaris/etc. This would keep the hub and hub management
out of the apps
> and keep the responsibility for the hub at a global level.

Again, I would agree - anything from windows 2K onward can be easily
configured to restart a service on failure, and the hubs are already
tolerant of restarts (using the clients file).

Within the install environment, it would be possible to check for the
existance of the hub service, and prompt the user - either to download
and install the hub there and then, or to confirm that they know what
they are doing? (an expert mode, basically)

Rather than have one hub, and one hub only - why not say that all hubs
written for windows have to use the same service name? that way, an
installer could look for that service by name when installing an
application, and I guess, set dependencies at that point - many
commercial apps do this, so it's not such a leap of logic.

Given that my "gimp" install the other night happily informed me
that I
had to get the GTK package first, I'm guessing this sort of behaviour is
not a million miles away from Linux either!

> Thoughts?

I would prefer a separate hub, but I think that we need to know what is
happening first - if there's a simple bug here that could be fixed, the
issue becomes academic... If we all had the crash free experience that
John is seeing, I don't imagine there would be any real desire to change
anything!

Ian.