For a list of related topics, see PEXlib Programming and PEX Protocol Levels.
You must make several important decisions when creating a PEXlib application that may encounter a variety of PEX protocol levels. If your application operates in a distributed heterogeneous environment, it is likely that the PEX servers in the network may support different protocol levels due simply to the timing of vendor releases.
This discussion only address different levels of the PEX Version 5 protocol. PEXlib 5.x will not operate with PEX version 4, for example.
You must decide what version of PEXlib to use (5.1 or 5.2) and what levels of the PEX protocol your application will work with (5.0, 5.1, or 5.2). The most straightforward path is to simply choose PEXlib 5.2 and restrict the operation of the application to servers that support only PEX 5.2. However, if your application does not rely heavily on PEX 5.2 functionality, it may be possible to code multiple paths to allow it to work with multiple protocol levels.
For a list of related topics, see PEXlib Programming and PEX Protocol Levels.
First, a quick word about libraries. If your application is written to PEXlib 5.1 specifications, then it also follows PEXlib 5.2 specifications. You are able to compile and link the same code with PEXlib 5.2 header files and libraries.
If you wish to use features that are unique to PEX 5.2, you must compile with PEXlib 5.2 libraries in order to access these PEX 5.2 functions conveniently.
It is also possible for you to use PEXlib 5.2 to access only PEX 5.1 or PEX 5.0 functionality. You may want to do this to take advantage of PEXlib 5.2 features like the OC Context for accessing older PEX function while remaining interoperable with older servers. Much of the rest of this appendix is devoted to using PEXlib in this fashion.
For a list of related topics, see PEXlib Programming and PEX Protocol Levels.
The first task is for the programmer to determine the protocol version that the server supports, so the program may behave accordingly. The information is available in a data structure returned by the PEXInitialize function, or by using the PEXGetExtensionInfo function:
int status;
PEXExtensionInfo *pexinfo;
char errstr[PEXErrorStringLength];
status = PEXInitialize( display, &pexinfo, PEXErrorStringLength, errstr );
if (status != 0) {
fprintf( stderr, "%s\n", errstr );
exit(0);
}
/* pexinfo->major - check to be sure it is 5 */
/* pexinfo->minor - check for 0, 1, 2, .... */
/* You can also obtain this info at any time by calling: */
pexinfo = PEXGetExtensionInfo( display );
Now that you know what version of the PEX protocol the server supports, here is an example of how you write code to deal with different levels:
if (pexinfo->minor >= 2)
PEXOCCSetInteriorStyle(context, PEXInteriorStyleTexture);
else
PEXOCCSetInteriorStyle(context, PEXInteriorStyleSolid);
This example simply set the interior style attribute of the pipeline state to the texturing state if the PEX server implementation is 5.2 or higher. The code uses ">=" because future versions of PEX will continue to support features that are currently defined. If the server is a 5.0 or 5.1 server, then this code uses the "fall-back" of telling the server to use the solid interior style.
Note that there is an important distinction between a feature being defined, as opposed to being supported. PEX 5.0 and PEX 5.1 do not define PEXInteriorStyleTexture, so if you send this value to a 5.0 or 5.1 server, you get a protocol error. In contrast, if you send this value to a 5.2 server that does not support this interior style, the implementation quietly uses the default interior style.
When the application can afford to use fall-backs as in the above example, you are able to code multiple paths that allow your application to work, to some extent, on older servers.