Applications Messaging Standard

[Doug Tody]

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.

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