Server Resources
Overview
Because ParaView is a client/server application, developers must deal with server protocols, server configuration, and server-side resources in a wide variety of contexts. To make them easier to manage the pqServerResource class provides a flexible, compact representation for a server-side resource that is based on Uniform Resource Identifier (URI) syntax.
Conceptually, each server resource is a string which encodes:
- Scheme - the protocol by which the resource can be accessed, such as "ftp:", "http:", "mailto:", etc.
- Host - the optional network host where the resource is located.
- Port - the optional non-default IP port where the resource is located.
- Path - the optional host-specific path where the resource is located.
ParaView resources can be converted between the familiar URI string syntax and instances of pqServerResource which provide convenient parsing and access to individual components of the URI.
Because the path component of a server resource is optional, a server resource can be used to represent either a server or a specific resource located on that server.
ParaView resources will typically use one of several custom, ParaView-specific schemes that are specific to the interaction between ParaView client and server:
Builtin
A server resource of the form builtin:/path/to/resource represents a resource located on the local host and accessed using client-only functionality. Note that host and port would be redundant in this case - the "builtin:" scheme never includes a server or port.
Client / Server
A server resource of the form cs://host:port/path/to/resource represents a resource located on a remote host, accessed using ParaView's client/server functionality. The host and (optional) port number designate the host where the server is running, and the (optional) path points to a file located on the remote host's filesystem.
Note that the "remote" host could also be a server running on the same host as the client, referenced using localhost or the loopback address 127.0.0.1.
Client / Server (reverse connection)
A resource of the form csrc://host:port/path/to/resource represents a resource located on a remote host, accessed using ParaView's client/server functionality using reverse connection mode where the server contacts the client. This may be necessary in certain networking environments where the server is behind a firewall or inaccessible due to network address translation. Note that the port number, if specified, is the port number that will be used by the client to listen for the server's connection. Once a connection is established, the (optional) path still references a file located on the remote server's filesystem.
Client / Data Server / Render Server
A resource cdsrs://dshost:dsport//rshost:rsport/path/to/resource references a resource accessed using ParaView's client/data server/render server functionality. In this case, separate data server and render server hosts must be specified, along with (optional) ports for each.
Client / Data Server / Render Server (reverse connection)
A server resource cdsrsrc://dshost:dsport//rshost:rsport/path/to/resource references a resource accessed using ParaView's client/data server/render server functionality in reverse connection mode. As with client/server reverse connections, the (optional) port numbers specified in the resource represent the ports that will be used by the client for listening.
Session
Session resources are more complicated than other resource schemes, because a saved ParaView session can contain two resources which may not be stored on the same host: the session file itself, and the server to be used for loading and displaying the session. Because of this, session resources take the form session:/path/to/session#<server>, where <server> could specify a server using any of the other ParaView schemes, e.g:
- session:/path/to/session#builtin:
- session:/path/to/session#cs://host:port
- and-so-on ...
Currently, it is not possible to save/load sessions from remote servers, so no host or port is provided before the session path. It is expected that in the future the session scheme will be expanded to allow for session host and port, so that a session file located on one server can be used to initialize some other server.
