1xpaintro(n)                   SAORD Documentation                  xpaintro(n)
2
3
4

NAME

6       XPAIntro: Introduction to the XPA Messaging System
7

SYNOPSIS

9       A brief introduction to the XPA messaging system, which provides seam‐
10       less communication between all kinds of Unix event-driven programs,
11       including X programs, Tcl/Tk programs, and Perl programs.
12

DESCRIPTION

14       The XPA messaging system provides seamless communication between all
15       kinds of Unix programs, including X programs, Tcl/Tk programs, and Perl
16       programs.  It also provides an easy way for users to communicate with
17       these XPA-enabled programs by executing XPA client commands in the
18       shell or by utilizing such commands in scripts.  Because XPA works both
19       at the programming level and the shell level, it is a powerful tool for
20       unifying any analysis environment: users and programmers have great
21       flexibility in choosing the best level or levels at which to access XPA
22       services, and client access can be extended or modified easily at any
23       time.
24
25       A program becomes an XPA-enabled server by defining named points of
26       public access through which data and commands can be exchanged with
27       other client programs (and users).  Using standard TCP sockets as a
28       transport mechanism, XPA supports both single-point and broadcast mes‐
29       saging to and from these servers.  It supports direct communication
30       between clients and servers, or indirect communication via an interme‐
31       diate message bus emulation program. Host-based access control is
32       implemented, as is as the ability to communicate with XPA servers
33       across a network.
34
35       XPA implements a layered interface that is designed to be useful both
36       to software developers and to users.  The interface consists of a
37       library of XPA client and server routines for use in programs and a
38       suite of high-level user programs built on top of these libraries.
39       Using the XPA library, access points can be added to Tcl/Tk programs,
40       Xt programs, or to Unix programs that use the XPA event loop or any
41       event loop based on select().  Client access subroutines can be added
42       to any Tcl/Tk or Unix program. Client access also is supported at the
43       command line via a suite of high-level programs.
44
45       The major components of the XPA layered interface are:
46
47       ·   A set of XPA server routines, centered on XPANew(), which are used
48           by XPA server programs to tag public access points with string
49           identifiers and to register send and receive callbacks for these
50           access points.
51
52       ·   A set of XPA client routines, centered on the XPASet() and
53           XPAGet(), which are used by external client applications to
54           exchange data and commands with an XPA server.
55
56       ·   High-level programs, centered on xpaset and xpaget, which allow
57           data and information to be exchanged with XPA server programs from
58           the command line and from scripts.  These programs have the command
59           syntax:
60
61             [data] ⎪ xpaset  [qualifiers ...]
62                      xpaget  [qualifiers ...]
63
64       ·   An XPA name server program, xpans, through which XPA access point
65           names are registered by servers and distributed to clients.
66
67       Defining an XPA access point is easy: a server application calls
68       XPANew(), XPACmdNew(), or the experimental XPAInfoNew() routine to cre‐
69       ate a named public access point.  An XPA service can specify "send" and
70       "receive" callback procedures (or an "info" procedure in the case of
71       XPAInfoNew()) to be executed by the program when an external process
72       either sends data or commands to this access point or requests data or
73       information from this access point.  Either of the callbacks can be
74       omitted, so that a particular access point can be specified as
75       read-only, read-write, or write-only.  Application-specific client data
76       can be associated with these callbacks.  Having defined one or more
77       public access points in this way, an XPA server program enters its
78       usual event loop (or uses the standard XPA event loop).
79
80       Clients communicate with these XPA public access points using programs
81       such as xpaget, xpaset, and xpainfo (at the command line), or routines
82       such as XPAGet(), XPASet(), and XPAInfo() within a program.  Both meth‐
83       ods require specification of the name of the access point.  The xpaget
84       program returns data or other information from an XPA server to its
85       standard output, while the xpaset program sends data or commands from
86       its standard input to an XPA application. The corresponding API rou‐
87       tines set/get data to/from memory, returning error messages and other
88       info as needed.  If a template is used to specify the access point name
89       (e.g., "ds9*"), then communication will take place with all servers
90       matching that template.
91
92       Please note that XPA currently is not thread-safe. All XPA calls must
93       be in the same thread.
94

SEE ALSO

96       See xpa(n) for a list of XPA help pages
97
98
99
100version 2.1.12                 January 26, 2010                    xpaintro(n)
Impressum