Chapter 8. Synchronous API

Index

Introduction
A simple C++ client: getting and modifying objects
stasher::client->get(): get objects from the repository
stasher::client->put(): update objects in the repository
stasher::client->getdir(): enumerate objects in the repository
stasher::client->subscribe(): object subscriptions
The updated() callback
stasher::client->subscribeserverstatus(): server status reports

Introduction

stasher's C++ API uses LIBCXX. Before using this API, it's necessary to have a good working knowledge of LIBCXX's template and class libraries. stasher uses LIBCXX's reference counted object classes and templates extensively.

This part describes stasher's synchronous API, one of several alternative APIs in stasher's C++ client libraries. These synchronous API methods take their input parameters, send a message to the client connection thread, wait for the message to get processed, and return the results. Internally they're basic on stasher's asynchronous API, which is slightly more complicated. The synchronous API implements a simplified interface, and would be appropriate for small scripts or non-critical batch jobs that do not need a high degree of fault tolerance.

Other stasher's API also use some concepts from the synchronous API, such as client handles and client connection threads. An application connects to a stasher object repository by creating a client handle, which represents a connection with the server's object repository node. The handle, an x::ref, is a reference to a reference-counted object. Although there is no explicit disconnection call, once the client handle goes completely out of scope, the underlying object gets destroyed, the client connection thread stops, and the connection to the server gets terminated.

The code examples in this part expect a basic stasher configuration, like the one described in Part I, “Managing the object repository cluster”: one of the server nodes in an object repository, with the server containing one node repository directory in the stasher library's default node directory; and the repository server process configured to place connections from client applications, by default, into the sandbox hierarchy.