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".
Schemes: "smb", "ftpe", "file" or "ftp"
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.