Applications Messaging Standard

[Mike Fitzpatrick]

On 2/12/07, Doug Tody <dtody at nrao.edu> wrote:
> I think we are talking about two different things here.  The VO registry
> would be used to discover applications or services available somewhere
> on the Internet; the scope is world wide.  A "message bus" on the other
> hand (PLASTIC is a simple version of one), registers connected apps for
> a desktop session.  The types of apps used in a desktop session often
> would not be available as services via the Internet (but they might
> still be described in the VO registry just so that one can find out
> about them).  The "hub" or message bus type of registry is more a type
> of naming service.

I don't think using the Registry for runtime access to capabilities is practical
or being suggested (although I might have said something along those lines).
As you say, using it to find an app when configuring a system is quite
different,
but then we need a separate discussion of how to register an app as being
V1.0 IVOAMsg (or whatever) compliant, as being a display/plot tool, etc.

> On the issue of using files to store/exchange metadata: this is just
> too problematic for a distributed system (except maybe for simple
> startup stuff).  Messaging is often used to link together modules in a
> distributed system, and this may well span multiple computers.  Files
> may not be visible from all participating nodes, plus there can be
> synchronization, caching, and platform issues.  Best to avoid files
> except perhaps for startup on the login/head node.

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.

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?

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?

-Mike