1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
=pod
=head1 NAME
B<XPAIntro: Introduction to the XPA Messaging System>
=head1 SYNOPSIS
A brief introduction to the XPA messaging system, which provides
seamless communication between all kinds of Unix event-driven
programs, including X programs, Tcl/Tk programs, and Perl programs.
=head1 DESCRIPTION
The XPA messaging system provides seamless communication between all
kinds of Unix programs, including X programs, Tcl/Tk programs, and
Perl 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 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.
XPA implements a layered interface that is designed to be useful both
to software developers and to users. The interface consists of a
library of XPA client and server routines for use in programs and a
suite of high-level user programs built on top of these libraries.
Using the XPA library, access points can be added to
Tcl/Tk
programs,
Xt
programs, or to Unix programs that use the XPA event loop or any
event loop based on select(). Client access subroutines can be added
to any Tcl/Tk or Unix program. Client access also is supported at the
command line via a suite of high-level programs.
The major components of the XPA layered interface are:
=over 4
=item *
A set of XPA server routines, centered on
XPANew(),
which are used by XPA server programs to tag public access points with
string identifiers and to register send and receive callbacks for
these access points.
=item *
A set of XPA client routines, centered on the
XPASet()
and
XPAGet(),
which are used by external client applications to exchange data and
commands with an XPA server.
=item *
High-level programs, centered on
xpaset
and
xpaget,
which allow data
and information to be exchanged with XPA server programs from the
command line and from scripts. These programs have the command syntax:
[data] | xpaset [qualifiers ...]
xpaget [qualifiers ...]
=item *
An XPA name server program,
xpans,
through which XPA access point names are
registered by servers and distributed to clients.
=back
Defining an XPA access point is easy: a server application calls
XPANew(),
XPACmdNew(),
or the experimental
XPAInfoNew()
routine to
create a named public access point. An XPA service can specify "send"
and "receive" callback procedures (or an "info" procedure in the case
of XPAInfoNew()) to be executed by the program when an external
process either sends data or commands to this access point or requests
data or information from this access point. Either of the callbacks
can be omitted, so that a particular access point can be specified as
read-only, read-write, or write-only. Application-specific client
data can be associated with these callbacks. Having defined one or
more public access points in this way, an XPA server program enters
its usual event loop (or uses the standard XPA event loop).
Clients communicate with these XPA public access points
using programs such as
xpaget,
xpaset, and
xpainfo
(at the command line),
or routines such as
XPAGet(),
XPASet(),
and
XPAInfo()
within a program. Both methods require specification of the name of
the access point. The xpaget program returns data or other
information from an XPA server to its standard output, while the
xpaset program sends data or commands from its standard input to an
XPA application. The corresponding API routines set/get data to/from
memory, returning error messages and other info as needed. If a
template
is used to specify the access point name (e.g., "ds9*"), then
communication will take place with all servers matching that template.
Please note that XPA currently is not thread-safe. All XPA calls must be
in the same thread.
=head1 SEE ALSO
See xpa(n) for a list of XPA help pages
=cut
|
