Re: xPL-Issue

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

>>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.
>
>
> No it's not - that's where the mutex comes in.

Well, except not all xPL frameworks are going to be able to participate in
a
O/S specific mutex call.  While mutexes are a common O/S idiom, they are
implemented differently enough that there isn't a clean way to deal with
them in a cross platform fashion (and in Java, for example, they are not
accessible without getting into binding native code in).

So while a V3 hub based app is OK, any other xPL apps that do not use that
framework are sort of left in the lurch.

Since xPL itself is not bound to any specific architecture, I would like to
put some thought into a way that hubs could be implemented that would be
available and dependable for any xPL app, regardless of platform or
framework used.

Right now, you'd have to *know* that the xPL apps you are running is V3
based or not in order to decide who/what should launch the hub.  Again,
that
isn't a good requirement for end users and will likely lead to problems as
multiple xPL apps are deployed.

> But this raises all sorts of problems for services - if a service
fires
> off a hub in a separate process, it will still be killed by the OS
when
> the service is stopped.

There is now way to create an independent process from a service?  That
would be unfortunate.

> But then you're back to having to distribute the rock-solid hub - and
> every app would need to install/detect whether this rock-solid hub was
> already present.

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.

> Port detection is fine for detecting a hub when your app starts.
> But suppose another hub is already running. You're going to have to
keep
> polling the port just in case the hub goes down - as you need to take
> over as quickly as possible.

I guess the idea of the apps being responsible for keeping a system
resource
like a hub running doesn't strike me as the right balance between app
autonomy, separation of responsibility and overall reliability.

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.

If we had a single hub for each platform that came with whatever
control/management that platform required to insure the hub is always
available, that would free all the dependencies from the apps (which would
just crap out if there were no hub (with an appropriate message)).  It
probably wouldn't be any worse than people having to have the .net
framework
installed before using a .net app (less, in fact, because this would be a
pretty small/quick download).

Thoughts?

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