goog.net.xpc.CfgFields

Authorization token. If set, NIX will use this authorization token to validate the setup.

Channel name identifier. Both peers have to be initialized with the same channel name. If not present, a channel name is generated (which then has to transferred to the peer somehow).

Ifame-ID identifier. The id of the iframe element the peer-document lives in.

Local poll URI identifier (IframePollingTransport-specific). The URI (can't contain a fragment identifier)which is polled to receive data from the peer.

Local relay URI identifier (IframeRelayTransport-specific). The URI (can't contain a fragment identifier) used by the peer to relay data through.

Which version of the native transport startup protocol should be used, the default being '2'. Version 1 had various timing vulnerabilities, which had to be compensated for by introducing delays, and is deprecated. V1 and V2 are broadly compatible, although the more robust timing and lack of delays is not gained unless both sides are using V2. The only unsupported case of cross-protocol interoperation is where a connection starts out with V2 at both ends, and one of the ends reconnects as a V1. All other initial startup and reconnection scenarios are supported.

Usually both frames using a connection initially send a SETUP message to each other, and each responds with a SETUP_ACK. A frame marks itself connected when it receives that SETUP_ACK. If this parameter is true however, the channel it is passed to will not send a SETUP, but rather will wait for one from its peer and mark itself connected when that arrives. Peer iframes created using such a channel will send SETUP however, and will wait for SETUP_ACK before marking themselves connected. The goal is to cope with a situation where the availability of the URL for the peer frame cannot be relied on, eg when the application is offline. Without this setting, the primary frame will attempt to send its SETUP message every 100ms, forever. This floods the javascript console with uncatchable security warnings, and fruitlessly burns CPU. There is one scenario this mode will not support, and that is reconnection by the outer frame, ie the creation of a new channel object to connect to a peer iframe which was already communicating with a previous channel object of the same name. If that behavior is needed, this mode should not be used. Reconnection by inner frames is supported in this mode however.

The hostname of the peer window, including protocol, domain, and port (if specified). Used for security sensitive applications that make use of NativeMessagingTransport (i.e. most applications).

Local poll URI identifier (IframePollingTransport-specific). The URI (can't contain a fragment identifier) used to send data to the peer.

Peer relay URI identifier (IframeRelayTransport-specific). The URI (can't contain a fragment identifier) used to relay data to the peer.

The URI of the peer page.

Remote party's authorization token. If set, NIX will validate this authorization token against that sent by the other party.

The frame role (inner or outer). Used to explicitly indicate the role for each peer whenever the role cannot be reliably determined (e.g. the two peer windows are not parent/child frames). If unspecified, the role will be dynamically determined, assuming a parent/child frame setup.

Transport type identifier. The transport type to use. Possible values are entries from goog.net.xpc.TransportTypes or a Transport constructor fuction. If not present, the transport is determined automatically based on the useragent's capabilities.