Applications Messaging Standard

[Doug Tody]

On Thu, 15 Feb 2007, Tony Linde wrote:
> The obvious answer to this in the windows environment is the registry: the
> hub writes its info there when installed and everyone knows where to look

My impression of the Windows registry is that it is only for fairly static
configuration info, not runtime stuff.  If it had a mechanism for sharing
info which goes away after a session without updating the registry store,
it might provide a Windows-specific global sharing mechanism.


On Thu, 15 Feb 2007, Mark Taylor wrote:
> Well that's the thing, isn't it - in most current usage scenarios there is 
> not something which serves this purpose.  The session mananger must
> (a) understand the messaging protocol well enough to be able to generate 
> connection bootstrap information (e.g. select an unused port),
> and (b) be relied upon to be the agency which starts up any application 
> wanting to participate in messaging conversations.
> In practice that means it must be something that we (definers of
> the messaging protocol) write, or influence the writing of,
> and it must be something which all users of applications use.
> In the era of specialist astronomical application environments
> (IRAF cl, Starlink ICL) this was perhaps a workable idea, but such
> things are hardly ubiquitous these days.  If the OPTICON proposals
> (http://archive.eso.org/opticon/twiki/bin/view/Main/WebHome) get
> off the ground that might provide such a platform, but (i) I don't
> think it would be wise to wait until that point before having a usable 
> messaging system and (ii) I don't think we should restrict use of any 
> messaging system to people working within any such particular environment. 
> In most cases, astronomers just want to click'n'go, and simply won't end up 
> using things which require
> rigid ways of working that they are not used to.

This is good stuff Mark, and basically I agree with all this.
We need to find a way for our desktop systems to be much more open,
and plug-and-play (yet still be able to do more than just have a few
stand-alone tools).

I think most of the issues with trying to use file-based mechanisms
in a distributed computing scenario can be avoided so long as we
do not use such a file-based mechanism for the runtime, once the
"bootstrap" has been completed.  It would be nice however to have
a scheme that can still work in a read-only file system scenario,
which doesn't alias multiple sessions to the same location, which
doesn't leave dreg files behind after a crash, doesn't have race
conditions as files are created and then written, etc.

With a file-based mechanism I think there will still be platform
issues, as Tony has mentioned.  On Windows the comparable mechanisms
are "C:\Documents and Settings", where application data is normally
stored (as a user I hate this as it is difficult to manage), and
the windows registry, where configuration data is stored.  It is not
clear the Unix-style of dot files under HOME carries over all that
well to Windows.  BOTH platforms however (and all modern platforms
I know of), do have comparable environment mechanisms, and networking,
which are good runtime mechanisms for concurrent programming.

The best alternative to a file-based mechanism for bootstrap might be
a simple network-based scheme of some sort.   Both PLASTIC and XPA for
example, already try to provide a simple runtime, socket-based naming
or registration facility.  A possible alternative might be to use a
portable mechanism such as the environment, with a built-in default
address which apps could fall back on, to define a shared socket
used to store simple keyword-value information via some trivial
standard protocol.  Given this we could bootstrap the messaging
system, and support unique per-session addresses and so forth (the
per-session messaging would dynamically assign a different, unique,
controlled-access socket).  Perhaps we should consider defining *two*
things: such an ultra-simple, network-based keyword store, and a
simple standard inter-tool messagaging protocol.  I suspect that the
simple keyword-store could be as useful as as the inter-tool messaging.

 	- Doug