Applications Messaging Standard

[Mark Taylor]

On Tue, 13 Feb 2007, Doug Tody wrote:

> Hi John -
>
> On Tue, 13 Feb 2007, John Taylor wrote:
>>> BTW, scanning the recent messages I still see a lot about dot files
>>> etc.  This is an implementation issue; platform specific issues such
>>> as dot files in U*nix can be dealt with by the implementation, and
>>> do not have to be addressed by the standard protocol.
>> 
>> Yes and no.   How one goes about getting the information required to 
>> connect could be part of the protocol.  You've already mentioned passing 
>> this in on the commandline when you start an application.  Another (and 
>> arguably more user-friendly) way would be to put this information in a 
>> well-known location on the file system where client applications can find 
>> it.
>
> The information content and how it is used in operations could be
> part of the protocol; how it is stored externally is part of the
> implementation.  User interface issues such as providing a file-based
> configuration mechanism which the user could edit is an implementation
> issue; a different implementation could store the same information
> in a different fashion.  That is not to say that it is not important,
> just that it is important to separate the two concerns.

I don't think John is talking here about a configuration file which the 
user would edit (see below for what I think he is talking about).

> Specifying connection information on the command line when an app is
> started is not normally something one would do in a user interface,
> rather such arguments would probably be autogenerated transparent
> to the user, when the actual user interface (e.g., a CLI, some GUI,
> etc.)  starts up the applications participating in the session.

This model can work if the the "actual user interface" in question 
understands which applications it can start up will/might participate 
in the messaging conversation and can transmit information to 
them about how they should connect to it.  But I don't see how it
can operate if applications are started up from some third-party 
environment such as /bin/sh or javaws.

> This is runtime information used to tell apps how to dynamically
> connect to a session; it is hard to even see how to reliably pass
> such information via files, even if we ignore issues such as could
> occur in a distributed or heterogeneous environment.

What is hard to see here?  The idea is that a service (the "hub")
writes information (such as a port number or URL) in a file at a 
well-known location (~/.ivoa-messaging) which describes how clients 
can connect to it.  The file effectively acts as a very simple naming 
service; messaging-aware applications can read the file to find out 
how they should connect to the current messaging session.  When the
"hub" shuts down it removes the file.  In this scenario the location 
and format of the file are part of the protocol not part of the 
implementation because participants in the protocol need to locate
and read it to bootstrap their connections.  Admittedly this
can't be easily extended to, say, multi-user scenarios and so it
may be that it's insufficient for the requirements of whatever 
messaging system we want to come up with, but "ignor[ing] issues 
such as could occur in a distributed or heterogeneous environment" 
I don't see any problem with it; as you may not be surprised to hear, 
it is exactly what is done in PLASTIC as well as a number of other 
systems providing informal interprocess communication I could name.

I feel we may have some implicit misunderstanding or disagreement
about how connection to a messaging service can work here.  Doug,
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.

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/