Applications Messaging Standard

[Tony Linde]

Phew. This thread was starting to get complicated. Glad everyone now seems
to agree with Doug, Paul etc that we need to keep this thing simple.

Perhaps, even, to obviate the problems John raises we mandate that the hub
is detached and startable via some mandated process which can be autostarted
at boot, manually started by user or kicked off by first app to require it.

T.

> -----Original Message-----
> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On 
> Behalf Of John Taylor
> Sent: 13 February 2007 11:04
> To: Doug Tody
> Cc: Mike Fitzpatrick; apps at ivoa.net
> Subject: Re: Applications Messaging Standard
> 
> 
> On 13 Feb 2007, at 01:18, Doug Tody wrote:
> 
> > Hi John -
> >
> > Must be getting to be time to get some sleep over there...
> >
> > On Mon, 12 Feb 2007, John Taylor wrote:
> >> application, but it was also a usability issue.  So we 
> started to get
> >> some authors bundling their own Hub into their apps.  
> These Hubs are
> >> pretty much separate applications to the host app (in 
> fact, the user
> >> usually is given the choice from within the host application of
> >> forking the Hub as a separate process) - you could argue 
> it's just a
> >> packaging convenience.
> >
> >> 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).
> >
> > I think this is too complicated and error prone.  There 
> should be one
> > "hub" (integrated messaging infrastructure of whatever type) per  
> > session.
> > If this "goes away", the session ends (with sophisticated  
> > implementations
> > it may not merely "go away" when a single process shuts down).   
> > Most apps
> > should just connect and assume that messaging is there or they  
> > function
> > standalone.  An app which can initiate a session might try 
> to connect,
> > and if that fails initiate the session.  What "initiate the session"
> > means depends upon the implementation.  In a simple 
> implementation it
> > could mean starting up a "hub" process/thread which is either in the
> > app or spawned as a daemon.
> 
> Hi Doug, I think we agree on this, though since my email was written  
> after midnight it might not have been as clear as it should have been.
> In the above paragraph I've dropped my idea that one Hub should  
> silently hand over responsibility to the next - one of our 
> scientists  
> tells me that they would actually like to have some control over  
> which Hub implementation they run.  I am making the point that some  
> application authors will still want to (semi)automatically start a  
> hub if one isn't running: whether they fork another process, 
> download  
> and run a Java webstartable hub or use an embedded one is not for us  
> to say.   We can however ask that they observe the rule that they  
> don't silently start a Hub when one is already running, and that if  
> they start a Hub and then shut it down for some reason they should  
> (probably) warn the user if other applications are still 
> connected to  
> it.
> There will still only be one Hub running during any session.
> 
> >
> > This should all be abstracted as we discussed earlier.  For  
> > something like
> > connecting to an existing session this can be very simple, e.g., a  
> > connect
> > with an opaque session-ID string passed in as a command line  
> > argument or
> > environment variable, and passed on to the implementation 
> as an opaque
> > string.  Whether this is just a port number or 
> user at host:port, a URI,
> > etc. is up to the implementation.  Initiating a session may 
> require  
> > more
> > information and may even want to be implementation specific, hence  
> > should
> > not be attempted by most apps except perhaps in a rudimentary form  
> > (e.g.,
> > localhost only, automated per-user-instance session, one or two  
> > clients).
> >
> > 	- Doug
> 
> 
> Or alternatively, read whatever connection info is needed 
> from a well- 
> known file as suggested a while back by Mike.
> I think at this stage we should concentrate on the localhost only,  
> "one user per session" case.
> 
> 
> >
> 
>