Document toolboxDocument toolbox

Vidispine

PlatformUri [VF 21.1 AgSDK]

Owned by Andreas Schmidt
Jun 02, 2021
2 min read

It is essential for users wishing to integrate against VidiFlow, that a comprehensive understanding of VidiFlow's specific URI concept is achieved. This becomes particularly relevant when it comes to naming and handling the input and output URI parameters for tasks.

DIAGRAM: ObjectUri Model

The highest level is occupied by the "ObjectUri". All other subsequent children URIs derive from the "ObjectUri".

ObjectUri

Children URIs

VpmsUri

PhysicalUri

PlatformUri

Scheme: "vpms"
These are URIs from the Worker Based VPMS" (VPMS2).
Please note that the new VPMS URIs (VPMS3) are now featured with the scheme "pf" instead of "vpms"! This is done with purpose of separate the contexts and avoid conflicts by renaming Worker Based VPMS (VPMS2) URI scheme into something within VidiFlow.

Schemes: "smb", "ftpe", "file" or "ftp"

Scheme: "pf"
Please note that the "pf" scheme is the designated URI for addressing all objects in the VidiFlow /Vidispine world.

When naming a parameter for URI, it is important to consider the nature of the different URI before choosing.

  • VpmsUri: if this is a Worker Based VPMS URI (VPMS2).

  • PhysicalUri: if the input URI is only valid if it has one of the following schemes; "unc", "smb", "ftpe", "file", or "ftp".

  • PlatformUri: if the input URI identifies a VidiFlow /Vidispine object.

  • ObjectUri: if the allowed runtime content may be more than one of the children types.

Since PlatformUris are an abstract representation of an object but actual tasks might need a PhysicalUri to access the "real world" object, there are some helper classes (see ItemReference, StorageReference, FileReference) that simplify the transformation between the two representations.
Note that due to the storage concept of VidiFlow, a PlatformUri might have several PhysicalUris to access the physical object depending on the "storage method" you choose to access it.