Applications Messaging Standard

[John Taylor]

On 12 Feb 2007, at 23:00, Doug Tody wrote:

> 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).

I just want to clarify that I wasn't suggesting every application  
need include the infrastructure/Hub.  Originally we had just the  
situation you suggest: a single daemon process (OK, it happened to be  
bundled inside the Workbench, but that was largely programming  
convenience as the two shared code and had a common heritage).   Then  
we started getting feedback that users didn't want to run a separate  
application.  No doubt this was partly due to the size of the  
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.


> 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps/attachments/20070212/cd731e73/attachment.html>