Applications Messaging Standard

[Doug Burke]

On Feb 13, 2007, at 8:21 AM, Thomas Boch wrote:

> Hi John,
>
>>>> I can see that not worrying about handover from one hub to another
>>>> would simplify things.  So we need to decide how to fire up such a
>>>> daemon if it's not already running.  We could just ask the user to
>>>> start it, I guess.  No doubt some app authors will still want to 
>>>> make
>>>> it seamless by spawning off a hub themselves.  In that case we'll
>>>> have to rely on good etiquette so that such hubs don't "bump" an
>>>> already running hub, and when the user tries to shut them down they
>>>> give fair warning if there are applications still using their hub
>>>> (and if closing the app implies shutting down the hub).
>
> That's more or less how Aladin is behaving (in the PLASTIC framework).
> It starts its own hub automatically at startup, only if no other 
> running
> hub has been detected (this behaviour can be disabled in preferences in
> order not to automatically launch the embedded hub). If the running hub
> shuts down, the user is warned, and he can startup manually the 
> embedded
> hub.
>
> Now, the case of multiple applications already connected to a hub which
> shuts down is more problematic. You can't just fire up a new hub and
> assume everything will be ok, as applications would have to re-register
> with the new hub.
>
> Generally, as Alasdair and you are stating, we should let maximum
> freedom to the user, as well as imposing as little as possible to
> developers willing to support the messaging standard in their
> applications. Embedded hubs should of course not be compulsory, but 
> they
> can be useful.

For CIAO (the Chandra data analysis software package) we make use of 
XPA [1] for inter-program communication (in the same way that ds9 
does). This makes use of a separate "name server" process [2] that acts 
as a registry of XPA-enabled programs that are currently running, so it 
has some of the functionality of the hub/bus concept discussed here. 
The server is automatically started by the host program if one does not 
already exist, and it lasts until the last XPA program exists, so it is 
similar to Aladin. We have found this to work well, and is invisible to 
the user (which is important). There are command-line tools and 
"scripting" language bindings, which are useful for debugging as well 
as allowing users to string together applications in surprising ways. I 
do not believe it deals with re-registration of applications when the 
name server itself dies; for our users this has not seemed to be a 
problem, so it could be argued that a *really simple*, single-user, 
single-desktop communication system does not need this facility (is 
this too simple even for Alasdair?).

I am not trying to suggest that XPA be used instead of PLASTIC. I just 
wondered whether the XPA experience here would provide any useful input 
to this part of the discussion.

[1] http://hea-www.harvard.edu/RD/xpa/
[2] http://hea-www.harvard.edu/RD/xpa/xpans.html

Doug