Containers become really useful when you use Liberator’s container windowing mechanism.
A simple subscription to a container of 200 currency pairs would cause the Liberator to send images and updates for all 200 instruments to the subscribing clients. This appears to offer little advantage over the client subscribing to each of the instruments individually and managing them locally. Containers become really useful when you use the windowing mechanism provided by Liberator. When a large number of instruments need to be managed, the benefits of using containers with windowing can be very significant - less memory and processor overhead in the client, and lower bandwidth usage between client and Liberator.
How container windowing works
The client requests the Liberator to provide a windowed view of the elements in the container, say a window of just 6 elements. The Liberator subscribes to just these 6 elements on the relevant Integration Adapter(s), and sends the images for these elements to the client and subsequently any updates to them.
The client maps the container window to a grid window in the client UI, so the end-user can see the 6 instruments being updated in real time.
Here’s a container window on elements 2 to 7 of a container that holds (for simplicity of illustration) 11 elements:
When the end-user scrolls down to the end of the displayed grid, the client changes the range of the window to the last 6 container elements (numbers 5 to 10) and passes this information to the Liberator as a container structure update request. (For example, a client using StreamLink JS to communicate with the Liberator would call the
setContainerWindow() method on an instance of
When the Liberator receives the container structure update request, it stops sending client updates for the instruments that are no longer in the window (elements 2, 3 and 4), but continues to send updates for the elements that have remained in the window (elements 5, 6 and 7). It also subscribes to the instruments that are newly in the scope of the window (elements 8, 9 and 10), sending the client the initial images and subsequent updates for them, like this: