Applications Messaging Standard

[Doug Tody]

On Mon, 12 Feb 2007, Mike Fitzpatrick wrote:
>
> The idea of a .ivoamsgrc directory was intended simply to be a startup
> file/ directory mechanism.  The thought being that each app could write
> it's own "capabilities database" file indicating the messages it handles,
> preferred type, of transport, task launch command, etc.  Other apps
> could read the same DB file to decide whether/how to send messages.
> These would be static files updated perhaps only with a new version of
> the software.  For startup, another file would keep track of who is
> 'connected' and in a world where users manually launch tasks every
> few seconds this normally would be manageable.  Firing up a "system'
> of multiple tasks (e.g. a small pipeline or an alias for multiple GUI
> tasks) could well have the syncronization problems you mention.

The simplest approach (this thing is supposed to be simple right?) would
be to somehow (external to the messaging facility) start up an app,
and have it connect to the bus.  All the apps needs is to know how to
connect, e.g, a string port specification like "user at host:port", which
could be passed in various ways, such as on the command line or via
the environment, perhaps with a session default.  Then the app can tell
the bus  or another client everything about what its capabilities are.
No files are required.

The issues of what apps are available and how to start them on local or
remote hosts, how to dynamically fire up an app which isn't running yet
in response to a client request, etc., is getting into the general issue
of execution frameworks and is not required at the level of a simple
protocol such as this is supposed to be.  In any case, this can be
addressed as a separate issue.

My impression with the simple inter-tool protocol was that 1) one would
start up the message bus ("hub" or whatever; maybe it is already running);
2) various apps would connect and register, telling what class of app
they are and what their capabilities are; 3) a client could then talk
to the app.

> Perhaps a .whatever directory as a local capabilities database (similar
> to the .plastic file) and a runtime registry (hub, embedded functionality,
> etc) of some kind is the simplest compromise?

Perhaps (although things start to get more complicated as noted above).
If so, a single file might be simpler.  This would be read only by
the bus/hub upon startup, then everything else can be done at runtime.
A system wide default could be provided.


> I'm still interested in ideas about how we keep the message contexts
> separated, i.e. how do I avoid seeing *your* data on *my* window if
> we're both on the same machine?

Sessions solve this problem, e.g., "user at host:port" or maybe
"user at host:session" with the obvious defaults, where "host" is the head or
login node (this reduces to localhost in the simplest case).  Sessions can
be public, per-user, per-session-per-user, etc.  The usual thing is to
identify the session in the head process and then propagate it on the
command line to every process which participates.  If an app is started
up manually and wants to join a session, one just needs to know what
the session is called and this can still be specified on the command line.
(OpenRTE and D-Bus do exactly this sort of thing for example).

	- Doug