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.