Adobe Version Cue CS3 Client Programmer’s Guide 23
Adobe Version Cue CS3 Client Programmer’s Guide
Version Cue Client Architecture
Version Cue Server plug-in provides a single point of integration with Version Cue for adding
server-side functionality, the same integration model is followed on the client side; that is, hav-
ing a single point of integration to add client-side functionality.
The mechanism that makes possible a single point of integration for client-side extensibility is
server-driven scripts sent to the client. This should not be confused with server-side scripting;
the scripts run at the client, but they are sent by the Version Cue Server to the client.
You can transmit JavaScript code from a Version Cue Server plug-in to Version Cue client
applications on certain events at the Version Cue Server. For instance, the first time an end
user of a Version Cue client application visits a standard Version Cue project, JavaScript code
can be sent from a Version Cue Server plug-in to the Version Cue client, to enable custom user
interface and logic to execute on particular events at the client.
To learn more about the architecture that supports this server-driven scripting integration
model, see Adobe Version Cue CS3 Server Programmer’s Guide.
Multi-threading
Version Cue clients are Adobe applications that are integrated with the Version Cue client
libraries. The Version Cue client library has a multi-threaded core, but sending and receiving
SOAP messages is serialized: although a single Version Cue client can have multiple threads
executing the library code, only one of its thread is sending/receiving at any one time.
The critical section in the client is protected by a synchronization object, a “baton” or mutex.
In a relay race, even if there are four runners in the team, only one at a time can hold the baton,
and similarly with running threads and the mutex. In Figure 12, two hypothetical requests are
shown, both of which try to acquire the mutex synchronization object, protecting access to the
critical section. The first to acquire the mutex proceeds to execute in the critical section, while
the other thread is blocked.
