Share

Understanding the IFFFS Wiretap Server Node Hierarchy

As noted in the introduction, a Wiretap server uses a navigable hierarchy of nodes to represent the structures it exposes. The IFFFS Wiretap Server exposes the structure of an IFFFS database, which is a clip library as a collection of project nodes, library nodes, and other related objects. The following diagram shows its node hierarchy.

Each project can contain an unlimited number of Workspaces, and each Workspace contains a protected hierarchy of components accessible to a single user.



IFFFS Node Types

All nodes have a type. Node types are case-sensitive strings. Each Wiretap server implementation defines its own node types using a set of string constants. The following table describes the node types of the IFFFS Wiretap Server.

IFFFS Node Type Description
NODE Generic node type. Mostly used as container nodes. The diagram above shows a number of container nodes that are of type NODE: setups, users, editing, effects, and preferences.
PROJECT A PROJECT node contains the entire creative finishing project containing all Workspaces and shared libraries, including clip libraries and setups for the various Creative Finishing modules that are used for the project. It also exposes metadata describing the project. Project metadata can be accessed as explained in Getting and Setting Metadata on a Project Node.

PROJECT nodes are children of the PROJECTS node.

A PROJECT node has the following child nodes:

  • Multiple WORKSPACE nodes
  • A Shared Library List node, which is a node of the type LIBRARY_LIST.
WORKSPACE A new project created by the IFFFS Wiretap server will not have any workspace, but a new Workspace is automatically generated upon starting the project in a Flame Family product. Existing Workspaces can be selected at the start-up screen.



Workspaces can be created as children of a project node using the WORKSPACE type.



A WORKSPACE node has the following child nodes, created implicitly:

  • One DESKTOP node
  • One LIBRARY_LIST node named Libraries.
DESKTOP A DESKTOP node contains:
  • One or more Batch groups for compositions, each containing a Batch Shelf and an Iterations folder (if shown). The Batch Shelf contains the Batch Renders reel and all Shelf reels. The Iterations folder contains all saved iterations and their associated reels.
  • One or more groups (if created), each containing reels for storing media on the Desktop outside Batch.

A DESKTOP can be saved to a library and later restored, or copied to a shared library to be shared across Workspaces.

A DESKTOP node has the following child nodes:

  • Multiple BATCH_CONTAINER
  • Multiple REEL_GROUP
Only one DESKTOP node can be created per WORKSPACE node.
BATCH_CONTAINER A BATCH_CONTAINER contains:
  • One SAVED_BATCH
  • One REEL_LIST
  • One SAVED_BATCH_LIST
REEL_GROUP REEL_GROUP contains multiple REEL nodes. One of these REEL nodes can be a special REEL, named Sequences. The Sequences reel is used in Connected Conform workflows (connected sources or connected shots).
SAVED_BATCH A SAVED_BATCH contains multiple REEL nodes.
REEL_LIST A REEL_LIST contains multiple REEL nodes. A REEL_LIST can only exist under a BATCH_CONTAINER. Moving a REEL_LIST from under a BATCH_CONTAINER node converts that REEL_LIST into a REEL_GROUP.
SAVED_BATCH_LIST A SAVED_BATCH_LIST contains multiple SAVED_BATCH nodes.
SETUP A SETUP node gives access to a setup file for a particular Creative Finishing module to be used for the project to which it belongs. The content of a setup file is accessed as explained in Getting and Setting Setups.

A generic NODE named setups contains the entire setups branch for a project.

Each SETUP node is a child of a generic NODE named for the Visual Effects and Finishing module in which it is used (Paint, CC, Keyer, and so on).

SETUP nodes are the leaf nodes in the setups branch. They have no child nodes.

LIBRARY_LIST A LIBRARY_LIST contains multiple LIBRARY nodes.

Only one LIBRARY_LIST node can be created per PROJECT or WORKSPACE node.
LIBRARY A LIBRARY node is a container for the following child nodes:
  • Multiple REEL nodes
  • Multiple CLIP nodes
  • Multiple FOLDER nodes
REEL A REEL node is a container which can only contain multiple CLIP nodes.

REEL nodes can be used to organize CLIP nodes. CLIP nodes can be stored directly in LIBRARY nodes.

CLIP A CLIP node exposes media in the form of frames. Its child nodes can be of the following types:
  • HIRES
  • LOWRES
  • SLATE
  • AUDIOSTREAM
  • VERSION
HIRES A HIRES node contains high-resolution video frames.
LOWRES A LOWRES node contains low-resolution video frames.
SLATE A SLATE node is an alias for the lowest resolution video clip node available (either a HIRES node or a LOWRES node).
AUDIOSTREAM An AUDIOSTREAM node represents a block of audio media.
VERSION A VERSION node represents a version, in the context of multi-version clips. There is one VERSION node for each version in the multi-version clip.


Sessions and commit to disk

Creating a new connection to an IFFFS Wiretap Server using a WireTapServerHandle will spawn a session on the server side. This avoids having multiple clients interacting destructively and keeps the project open, making subsequent calls faster.

The node hierarchy is automatically saved 2 seconds after the last operation in the session. The operation can be forced by making the following call on a given node handle:

C++

nodeHandle.setMetaData("COMMIT", "");

Python

nodeHandle.setMetaData("COMMIT", "")

Not every node supports atomic commits. For example, doing a commit on a clip node will commit the parent library/workspace node; doing a commit on the project node will commit everything.

This operation is not required when working with command line tools since every command line tool will create its own sessions and commit on exit.

Was this information helpful?