Applications Messaging Standard

[John Taylor]

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.


>