xpatemplate(7) [debian man page]
xpatemplate(7) SAORD Documentation xpatemplate(7) NAME
XPATemplate - Access Point Names and Templates SYNOPSIS
XPA access points are composed of two parts: a general class and a specific name. Both parts accept template characters so that you can send/retrieve data to/from multiple servers at one time. DESCRIPTION
When XPA servers call XPANew(), or XPACmdNew() to define XPA access points, they specify a string identifier composed of a class and a name. When clients communicate with XPA access points, they specify which access points to communicate with using an identifier of the form: class:name All registered XPA access points that match the specified identifier will be available for communication (subject to access control rules, etc.) As of XPA 2.1.5, the length of both the class and name designations are limited to 1024 characters. The XPA class:name identifier actually is a template: it accepts wild cards in its syntax, so a single specifier can match more than one XPA access point. (Note that the class is optional and defaults to "*".) The allowed syntax for clients to specify the class:name tem- plate is of the form shown below. (Note that "*" is used to denote a generic wild card, but other wild cards characters are supported, as described below). template explanation -------- ----------- class:name exact match of class and name name match any class with this name *:name match any class with this name class:* match any name of this class *:* match any access point In general, the following wild-cards can be applied to class and name: wildcard explanation -------- ----------- ? match any character, but there must be one * match anything, or nothing [...] match an inclusive set Although the class:name template normally is used to refer to XPA access points, these also can be specified using their individual socket identifiers. For inet sockets, the socket identifier is ip - port, where ip can be the DNS-registered name, the ASCII IP number (e.g. 123.45.67.890) or the hex IP number (e.g. 838f3a60). For unix sockets, the identifier is the socket file name. These socket identifiers are displayed as the fourth argument in the xpans display of registered access points. For example, consider the ds9 program started using inet sockets. The xpans name server will register something like this: csh> xpaget xpans DS9 ds9 gs saord.harvard.edu:3236 eric You can access ds9 using ip:3236 in any of the three forms: csh> xpaget saord:3236 file /home/eric/data/snr.ev csh> xpaget 123.45.67.890:3236 file /home/eric/data/snr.ev csh> xpaget 838f3a60:3236 file /home/eric/data/snr.ev In the case of unix sockets, the socket identifier is a file: csh> xpaget xpans DS9 ds9 gs /tmp/.xpa/DS9_ds9.2631 eric csh> xpaget /tmp/.xpa/DS9_ds9.2631 file /home/eric/data/snr.ev This feature can be useful in distinguishing between multiple instances of a program that all have the same class:name designation. SEE ALSO
See xpa(7) for a list of XPA help pages version 2.1.14 June 7, 2012 xpatemplate(7)
Check Out this Related Man Page
xpaintro(7) SAORD Documentation xpaintro(7) NAME
XPAIntro - Introduction to the XPA Messaging System 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. 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 mes- saging to and from these servers. It supports direct communication between clients and servers, or indirect communication via an interme- diate 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: o A set of XPA server routines, centered on XPANew(), which are used by XPA server programs to tag public access points with string iden- tifiers and to register send and receive callbacks for these access points. o 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. o 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 ...] o An XPA name server program, xpans, through which XPA access point names are registered by servers and distributed to clients. 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 rou- tines 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. SEE ALSO
See xpa(7) for a list of XPA help pages version 2.1.14 June 7, 2012 xpaintro(7)