Applications Messaging Standard

[Doug Tody]

On Mon, 12 Feb 2007, John Taylor wrote:
> Now, originally there was a single Hub implementation that you needed
> to have running in order to use PLASTIC.  This was distributed as
> part of the Astro Runtime.  However, it soon became clear that
> authors of many applications would want to embed a Hub inside their
> application, obviating the need for the user to start a separate
> application just to use PLASTIC.   It doesn't matter which
> application contains the Hub...it doesn't really make any difference
> as far as the client application goes.  At any one time you have a
> single Hub running and it will usually be hosted by the first
> application to start.
> I think this approach is turning out rather well...it means that the
> user doesn't need to be so aware of a Hub.

> A problem we haven't yet tackled is how to deal with a Hub dropping
> out when an application closes - we would then need a new one to
> start to pick up the slack.  I'm interested to know if we could do
> this without the user even being aware of it.

A simple approach is for the "hub" or message bus to be separate from
the apps, e.g., a separate daemon process, or a thread in some existing
system process which will run the entire session.  Then apps can come
and go and the overall session is unaffected.

Having the messaging infrastructure be part of each participating process
is also possible, but this requires linking a library or some other form
of module into each participant (CORBA works that way for example).
This can make it possible to provide additional capabilities, such
as support for point-to-point messaging between peers, but this does
require linking some sort of module into each client, which would have
to be done separately for every language.  Usually you end up needing
some separate daemons or services in any case.

For a simple protocol this sort of thing should be transparent.
The simplest approach is probably for the logical view to be a single
"hub" process or thread, one per session, which lives somewhere, depending
upon the implementation.

	- Doug