Applications Messaging Standard

[Doug Tody]

Ok, I agree that the single file is probably the simplest approach for
the bootstrap, so long as a file is used only for the bootstrap and
everything thereafter is based on messaging.

Tony: by LAN all I meant was not wide-area networking (not grid).
I think this bootstrap business only needs to work on a single
computer, and once we get into something which is network-based and
hides the implementation, it should be possible to do more general
distributed computing as well.  Hence we can probably largely ignore
the more general case for now.

On Fri, 16 Feb 2007, John Taylor wrote:
> On 15 Feb 2007, at 18:18, Mike Fitzpatrick wrote:
>> For this exercise we should concentrate on what information needs to be
>> written to establish the connection and pass messages.
>
> A typical file looks like this:
> plastic.xmlrpc.url=http\://10.0.0.12\:8001/4200a0f243b49ebc/xmlrpc
> plastic.version=0.5
> plastic.rmi.port=1099

Anything which is just a set of keyword-value pairs in a text file
with a simple syntax should do just fine.  XML would be overkill for
this purpose.

> Can anyone explain to the group what XPA does?

It would be best to hear from the SAO folks about this (Eric Mandel
originally developed XPA), but here are some words from their web page.
You can find out more at http://hea-www.harvard.edu/RD/xpa/.

     The XPA messaging system provides seamless communication between many
     kinds of Unix programs, including X programs and Tcl/Tk programs. It
     also provides an easy way for users to communicate with these
     XPA-enabled programs by executing XPA client commands in the shell
     or by utilizing such commands in scripts. Because XPA works both at
     the programming level and the shell level, it is a powerful tool for
     unifying any analysis environment: users and programmers have great
     flexibility in choosing the best level or levels at which to access
     XPA services, and client access can be extended or modified easily
     at any time.

     A program becomes an XPA-enabled server by defining named points of
     public access through which data and commands can be exchanged with
     other client programs (and users). Using standard TCP sockets as a
     transport mechanism, XPA supports both single-point and broadcast
     messaging to and from these servers. It supports direct communication
     between XPA clients and servers, or indirect communication via an
     intermediate message bus emulation program. Host-based access control
     is implemented, as is as the ability to communicate with XPA servers
     across a network.

The original implementation was based on X, but the most recent version
appears to be purely socket-based.

 	- Doug