Re: xPL-Issue

[Gerry Duprey <gerry@xxxxxxxxxxx>]

Howdy,

> - at the time I wasn't aware there were so many other technologies
used - I
> thought most people were using services written in dot-net.

That's why I often come in as a shrill harpy on issues that affect
multi-platform deployment.  One of the reasons that I like xPL and have
dedicated to using it for all my HA related development was that it is
platform neutral (as a protocol).  It doesn't use any funny encodings or
idioms that work on one O/S but not on another.

So whenever an issue comes up that deals with something at the protocol
layer, in multi-framework cooperation or, in this case, at the layer of
minimum requirements for an xPL app to work, I'll be there :-)

>  2) Seperate hub

... and ...


> Please add to this list of PROS / CONS.
>  PROS
> - one seperate application responsible for hubbing
> - can make use of the underlying OS' ability to restart on failure
> - if the source is updated only one application must be updated

- Every single program/framework doesn't need to carry yet another
part of the plumbing around with it.
- Less likely for there to be any hub related bugs (though hubs are
pretty simple, but...)
- No confusion about what you need -- you *have* to have a hub
installed and I'd further suggest no app auto-installs a hub
for someone as it's a "sneaky" thing and may conflict with
another hub the app cannot detect).  I understand this isn't
as easy as now, but it's not very hard and there is plenty
of precedent for it (.net framework download).

>  CONS
> - it is a seperate and mandatory install
> - it may confuse new users
> - overkill in the scenario where a user is running xpl applications
only
> (not services)
> - it must be distributed to end-users (versus to developers only)

All valid, though I think solvable/tolerable.  For example, my DVArchive
project (non-xPL) is written in Java, so all users of DVA (and at last
count, that was about 47,000) must download Java first (if they don't
already have it).  There is a link on the DVArchive download site to Java
and a note about them needing it.  It's also in the FAQs.  While folks have
sometimes ignored those and posted questions like "Where is
Java", it's a
very small minority of folks (like less than 50 over 3 years).  Most folks,
given appropriate instruction, have no real problem with it.

As long as we make it clear on the downloads that you need to have a hub,
have links right there pointing to a list of hubs for various platforms and
for those folks with installers (like Installshield stuff), make obvious
statements that it's needed, I don't think the extra 5 minutes it'll take,
if that, is too big a stumbling block.

While this is hyperbole to be sure, right now, we have hub chaos.  Apps are
trying to provide/start/monitor something that really isn't in the domain
of
that app (it's a system-y thing), different apps using different
technologies can conflict and there is conflicting and confusing info for
anyone who starts in xPL about what the hub is and if they need it or not.
Doing this brings a level of clarity to the process.

>  I vote for the built-in functionality (surprise! ;-) As an end-user I

I like that too, but I think it's becoming problematic with each hub trying
to figure out if it should be starting a hub, watching for a hub to die,
etc.

> dislike applications that install services of which I do not know what
they
> are doing. And how do I know when to uninstall them ? Having a
seperate

In a way though, that is what is happening today.  Some apps are starting
hubs without saying anything and while this often is a convenience, when
something does go wrong, it's complete under the radar.

>  3) Mutexes
...
> way of detecting the need to start a hub. As long as the last xPL
> application alive starts a hub. If there is some cross-platform
standard for
> inter-process communication then it would perhaps be better to use
that
> (does it exist?). But for now the Windows dot-net implementation uses
> mutexes to answer the question "must a hub be started".

I'm not aware of any cross platform solution to mutexes.  Most O/Ss provide
a service that is basically the same as a Windows Mutex, though it may go
by
other names and have differing APIs.  The concept, but not the
implementation, is pretty common.

But the more xPL apps I write and run (mine and others), the more I feel
that applications should not be the ones trying to keep the hub alive (or
starting it).

I really feel that each platforms hub(s) need to be somewhat tailored to
that environment/OS so that it has the ability to auto-restart if it dies
and that xPL apps have no real knowledge of it.  In fact, I think an xPL
app
should not start if there is no hub detected and put up/print out an error
explaining why (vs. silently failing).  The means for keeping a process
running all the time/restarting it isn't difficult, but does vary.

In the end, as much as the xPL protocol is platform neutral, it really does
require, at least for network based xPL, a hub -- it really is part of the
plumbing and I think we need to look at treating it separately as such.

Off my soap box for my weekly movie night,

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