Applications Messaging Standard

[Mike Fitzpatrick]

On Thu, 8 Feb 2007, John Taylor wrote:

> 
> On 8 Feb 2007, at 17:19, Doug Tody wrote:
> 
> > On Thu, 8 Feb 2007, John Taylor wrote:
> >
> >> On 8 Feb 2007, at 15:12, Doug Tody wrote:
> >>
> >>>    o	Separate protocol from implementation.  That is, we should be
> >>>    	able to implement a message bus/hub in different languages such
> >>> 	as Java or C, or layer the protocol on top of an existing robust
> >>> 	messaging infrastructure such as D-Bus, MPI, PVM, ActiveMQ,
> >>> 	Ice, CORBA, etc.  It is fine to have a simple hub (or two)
> >>> 	developed as part of the standard, which doesn't queue messages,
> >>> 	guarantee delivery, and so forth.
> >>
> >> I agree that this is desirable.  There might be a trade off here  
> >> between the wire protocols we can offer in a Hub, and the  
> >> languages it is possible to use to write one.  We probably don't  
> >> need to worry about as many languages as we do for client  
> >> applications messaging though.
> >
> > At least for the simpler wire protocols, it should be possible to  
> > implement
> > the infrastructure with almost any language or technology.
> 
> Possible, but not necessarily practical.  I'd be happy to live with  
> not being able to write a "Hub" in IDL if that was the sacrifice  
> necessary to include easy-to-use protocols in the hub.  My point is  
> that the set of languages in which we need to write a Hub is  
> different, and probably smaller than, the set of languages we need to  
> support for clients.  It might be useful to know what these languages  
> are so that we can decide what wire protocols are of interest.  It's  
> even possible we could make some or all of the wire protocols  
> optional, but as Mark pointed out, that needs some careful thought.


	Be careful about how you distinguish the messages from the 
transport protocols.  The concept of the 'Hub' comes from the current 
PLASTIC implementation, but it is fair to consider whether a Hub is
needed at all.  There are a number of ways to deliver the message that
don't require a central Hub knowing which applications are available.
Note one of the use cases we should address is one where multiple users
are running on the same machine, i.e. do they share a 'Hub' or instantiate
their own (if so how do they address it).  The problem is the same if we
ignore a Hub and use a pub-sub or broadcasting method of some kind, how
are the messages from one user not confused with those from the other?

	To keep things simple I agree we should be looking at 
single-machine, inter-tool messaging -- but department servers still 
exist in the real world.  By separating the message from the transport,
a Hub could be written that understands existing PLASTIC and any other
transport and bridge the two.  Likewise we can avoid worrying about a
more general LAN/WAN messaging scheme by assuming some clever person 
will write an 'app' that acts as a router between desktops in a much 
bigger system.  Doug's comment about an 'adapter' fall into this same
catagory of what I shall now declare to be called "support apps".

-Mike