Applications Messaging Standard

[Mark Taylor]

Doug,

thanks for your response.

On Wed, 14 Feb 2007, Doug Tody wrote:

> I can see where an automatic auto-connect mechanism such as you
> describe could be convenient, but it is unusual.  When software tries
> to get smarter than whatever drives it this often leads to problems,
> making the software harder to use in some cases; it is better to
> tell it what to do.  Hence we use explicit command line arguments,
> environment variable triggers/defaults, and so forth.

I yield to no man in my abhorrence of clever software.  Furthermore, 
as an application author, I would like nothing better than to have
the environment (e.g. command-line args, environment variable) tell 
me how to connect to a messaging system.  But...

>> could you give an explicit scenario for how you envisage a client
>> application could bootstrap its connection to the messaging system?
>> Your story about a UI transparently autogenerating arguments seems to 
>> describe a skeleton for this but I don't know how you
>> see the details being filled in.
>
> It should be easy if the connection information can be optionally
> provided on the command line when an application is started.  One just
> passes an opaque string containing the necessary connection info.
> Something which knows what to do with this information is also
> required: either a library with a standard API, or we have to
> say something public about how to parse the connection info.
> Multiple sessions, distributed execution, etc., are easily supported.
> An environment-based approach is similar and in fact they are often
> combined.  This solves the problem for the application,

so far so good.

>                                                         but puts it
> off on the "session manager" which has to spawn the hub/bus and pass
> the info.  This is no problem so long as we have something which
> serves this purpose, and it is the more general approach, but it
> does require more than the simple auto-connect mechanism.

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.

> Off-hand I am not sure how best to solve a problem like this.  A simple
> approach might be to require at least an environment variable,
> possibly with an optional command line override, to trigger the
> connection attempt and provide connection information.   Defining a
> standard API would also provide a way to hide whatever is required,
> but would require more than just a wire protocol.

A standard API suggests language dependence, or at least an 
extension of the standard for each newly endorsed language - 
to be avoided if at all possible in my view.

>                                                    We might also
> consider whether a simple, general naming service would be worth
> defining for this sort of thing (XPA, being based on the X server,
> which is unique for a user session, has this by the way; it supports
> user sessions, distributed execution, and authentication - of course
> it is also obsolete technology, and a bit platform specific).

If there was such a pre-existing service which we could rely on finding
in a usable state on the platforms which we needed to service, 
that would be great.  Since there isn't, we'd need to specify one 
(or mandate use of an existing one) and ensure that everybody who 
wanted to run messaging-aware applications was running it. 
And then figure out the protocol via which each participating 
application works out how to communicate with it.  Back to square one.

In conclusion, I agree that storing bootstrap information in a ~/.ivoamsg
file is a bit clunky and inelegant, and a bit fiddly from an application 
author's point of view.  However it has the great advantage that it 
requires no supporting system infrastructure other than a writable
filesystem with per-user namespacing, and thankfully this exists on all
the platforms that we want to support.  If you're still unhappy with
this proposal, maybe you could

   1. give examples of the problems you forsee in using it
      (explicit consequences of your concerns about software being too
      smart in this context)

and

   2. EITHER give an alternative mechanism for connection bootstrapping
      which requires no supporting infrastructure beyond what we can
      expect to find on all useful platforms

      OR say what additional supporting infrastructure you think we
      should require, and what burden you expect this to impose on
      users (such a burden may not be very great, but my feeling is
      that any actions users need to take additional to starting up an
      application in whatever is their preferred fashion will reduce
      take-up substantially.  Others may of course disagree).

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/