xpainfo(3)

πŸ“¦
version 2.1.20 Β· 2 versions
  • 2.1.20 Β· debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking (latest)
  • 2.1.20 Β· fedora 43, fedora 44
, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’Œ xpainfo(3) β€” the XPAInfo glow-up

okay bestie, welcome to the xpainfo(3) page, straight outta the SAORD Documentation squad ✨ this one's all about XPAInfo, which sends a short lil message to one or more XPA servers. it's giving "hey girl, quick heads up" energy, and honestly? iconic.


🌸 NAME 🌸

XPAInfo β€” send a short message to one or more XPA servers πŸ’¬


✨ SYNOPSIS ✨

#include <xpa.h>

int XPAInfo(XPA xpa,
            char *template, char *paramlist, char *mode,
            char **names, char **messages, int n);

like yes, that's the whole vibe. six args, no drama. πŸ’…


πŸŽ€ DESCRIPTION πŸŽ€

so basically, XPAInfo sends a short paramlist message to one or more XPA servers whose class:name identifier matches the template you gave it. no cap, that's the whole job.

here's the tea: a template of the form "class1:name1" gets sent to the XPA name server, and the name server comes back with a list of at most n matching XPA servers. then a connection gets established with each of those servers, and the paramlist string is passed to the server as the data transfer request is initiated. if an XPA struct is passed to the call, then the persistent connections get updated as described above. otherwise? temporary connections are made to the servers, and those lil guys get closed when the call completes. 🫢

important: XPAInfo() does not send data from a buf to the XPA servers. only the paramlist is sent. periodt.

the semantics of the paramlist is not formalized, but at a minimum it should tell the server how to get more information. for example, it might contain the class:name of the XPA access point from which the server (acting as a client) can obtain more info using XPAGet. iykyk. πŸ’‘

a string containing the class:name and ip:port of each server is returned in the name array. if a given server returned an error, or the server callback sends a message back to the client, then that message gets stored in the associated element of the messages array. the returned message string will be of the form:

XPA$ERROR   error-message (class:name ip:port)

or

XPA$MESSAGE message     (class:name ip:port)

the return value contains the actual number of servers that were processed πŸ‘‘ which means it holds the number of valid entries in the names and messages arrays, and you can use it to loop through those arrays. and if names and/or messages is NULL, no information is passed back in that array. simple as. 😌

the following keywords are recognized:

key           value           default         explanation
------        --------        --------        -----------
ack           true/false      true            if false, don't wait for ack from server

now listen, when ack is false, XPAInfo() will not wait for an error return from the XPA server. this means, in effect, that XPAInfo will send its paramlist string to the XPA server and then exit: no information will be sent from the server to the client. this UDP-like behavior is essential to avoid race conditions in cases where XPA servers are sending info messages to other servers. fr fr. if two servers try to send each other an info message at the same time and then wait for an ack, a race condition will result and one or both will time out. 😭 messy, we don't want that.

Example:

(void)XPAInfo(NULL, "IMAGE", "ds9 image", NULL, NULL, NULL, 0);

look at her go. πŸ’–


πŸ”₯ SEE ALSO πŸ”₯

see xpa(n) for a list of XPA help pages 🌈


mwah πŸ’‹ that's the page! this lil manual came to you courtesy of version 2.1.15, dated July 23, 2013 β€” old but iconic, a true vintage queen. go forth and send ur messages, bestie πŸ¦‹βœ¨