Galaxy Communicator Documentation:

Upgrading from 3.1 to 3.2

License / Documentation home / Help and feedback

Upgrading to Galaxy Communicator 3.2 is simple. For almost all users, there are no obligatory upgrades.

This document describes only the steps required or recommended to upgrade existing features of Galaxy Communicator. You can find a list of new features here. You can find the complete release notes here.
 
 
Step Who's affected Status
Step 1: Updating session management in the Hub All users of session locks and multiple sessions Obligatory
Step 2: Upgrading flags which set Hub client behavior All users of Hub clients (not for Java yet) Obligatory


Step 1: Updating session management in the Hub

The Hub chooses service providers based on a number of considerations: whether they support the requested operation, whether they're free, whether they're up, and what sessions they may be restricted to supporting. In version 3.1, being the only provider for a particular service outweighed the session the provider was restricted to supporting, so that if there was, say, only one audio server, and it was locked to session 1, programs running tokens in session 2 would still be allowed to select that server, because it was the only one. This behavior was incorrect, and it has been fixed.

However, if you have been experimenting with session locks and multiple sessions, it's possible that at this point your system might stop working, because you've unwittingly relied on this bug in 3.1. So if in 3.2, your system informs you that there are no providers available when you believe that there are, you should consider the possibility that you've misused session locks.


Step 2: Upgrading flags which set Hub client behavior

When you set up a Hub client programmatically, it's possible to define the behavior of the Hub client when it cannot establish a connection, or when it loses one. As of version 3.2, it's possible to specify that the process should shut down if it can't establish a connection, where before it was not possible to do so. It's also possible to check the conditions more mnemonically than before, because new masks and constants have been added. In some cases, because the values of the constants have changed, this change is obligatory.

For instance, if you want to see if the server was set up to retry, you would previously have need to do this:

Version 3.1

if (!(GalIO_ServerListenStatus(scomm) & GAL_HUB_CLIENT_CONNECT_FAILURE_NOOP)) {
  ... }
This will now do the wrong thing. The proper (and more mnemonic) test is

Version 3.2

if ((GalIO_ServerListenStatus(scomm) & GAL_HUB_CLIENT_CONNECT_FAILURE_MASK) ==
    GAL_HUB_CLIENT_CONNECT_FAILURE_RETRY) {
  ... }
See the documentation on GalIO_ServerListenStatus for more details.
License / Documentation home / Help and feedback
Last updated October 4, 2001