Applications Messaging Standard

[Mike Fitzpatrick]

On Fri, 9 Feb 2007, Mark Taylor wrote:

> On Fri, 9 Feb 2007, Doug Tody wrote:
> 
> > Hi Mark -
> >
> > I think we are actually saying the same thing.  If we define a
> > standard inter-tool messaging protocol and implement it on top of,
> > e.g., D-Bus, you client does not talk directly to D-Bus, it talks to
> > an implmentation of the defined messaging standard which just happens
> > to use D-Bus, MPI, Ice, or whatever internally.  It is not a compliant
> > implementation unless a standard interface is presented which isolates
> > the client from the underlying messaging infrastructure used.
> 
> good, I'm quite happy with that.  In that case I don't think there's
> much call for discussion here about what underlying messaging 
> infrastructure is used, since as you say that's a matter for the 
> implementations.  What we need to get straight is what the 
> client-facing interface should look like.

	[A few comments and questions.  I plan to update the Twiki later
today with a list of what appear to be agreed points and those still under
debate so they can be distilled more easily from a very lively exchange 
and other comments appearing on the Twiki questions page.]

	I would remind you of an earlier comment that we agree on at least
one transport protocol that all compliant implementations support, so I 
think there is still some room for discussion on this point.  BTW, I 
checked the RFC for HTTP and is only says that TCP sockets will 'usually'
be used, the protocol itself doesn't preclude any other form of transport
and so your example is very relevant.

	I haven't yet heard a call for the definition of a standard API
but I think we need at least a straw description of one to talk about the
behavior of the interface, e.g. does a sendMessage require an ACK, is 
there some standard "header" to a message, is there negotiation between
apps when connecting to determine compatability, is a message immutable
between transport methods or is a PLATSIC 'loadImage' message  as good as 
a D-Bus one, etc.

	Lastly, people are still talking about the/a 'hub':  My 
understanding is that this is an artifact of the RMI used in PLASTIC, but
some apps have embedded hubs and in other cases it's a standalone process.
PLASTIC apps all connect to the hub in a point-to-point manner (please
correct me if I'm wrong so far).  So, is the 'hub' in question a simple
registry of apps and mini-router or does it, or the idea of it, serve some
other purpose we need to preserve?  Can a "$HOME/.ivoamsgrc" directory
containing user preferences, a local app capability registry, caches, etc
serve the same purpose (it's a well-known location to all apps so 
provides separation between users on the same machine, apps can update 
their capabilities db w/ each new version, scribble a file saying who's
"connected",  no real Registry lookups so it'll continue to work 
while you're on the plane, etc)

-Mike