Applications Messaging Standard

[Doug Tody]

On Fri, 9 Feb 2007, Mike Fitzpatrick wrote:
> 	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.

As you say, it will be necessary to define the API (operations,
messaging capabilities, etc.), and mappings to several standard
wire formats.  This is pretty much what will be required to define
the standard protocol.


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

I suggest it is better to do all this dynamically with messaging.
It is best to maintain state (such as list of registered clients
or services) in only one place, and there can be issues with file
synchronization and such in a distributed/concurrent system, which
it is best to avoid.

The concept of a "hub" (ignoring issues of the actual network topology)
which all clients in a session connect to, is a reasonable way to
provide this.  Physically, this could be a simple daemon process or
component within some other process as with the PLASTIC hub, or it
could be a distributed message bus spanning multiple computers in a
different implementation.  This is an implementation issue and need not
be visible to a client.

 	- Doug