What does the Harlequin Scalable RIP look like when delivered to you?
This page applies to Harlequin v13.1r0 and later; and to Harlequin Core but not Harlequin MultiRIP
This section describes at a high level what a Scalable RIP looks like as a deliverable. HHR can be used in three scaling modes:
Single RIP | Multiple RIPs on one server | Multiple servers | |
Naming | Harlequin Core | Single-server Harlequin Scalable RIP | Multi-server Harlequin Scalable RIP |
Use case | Light production, simplest integration | Relatively simple integration for devices that are fast enough to require more than one RIP | Maximum throughput for devices with very high data rates, at the cost of more complex integration |
Simple integration | Command line or hotfolder use or clrip.exe. | Command line or hotfolder use for clrip.exe using the nrips option | None |
Tight integration in HHR | Rework/replace skintest layer in SDK to connect to your DFE functionality. | Separate binary built on SDK code with additional requirements over simple HHR: Must include argument parsing and be built to be self-spawning; example client code can be built into your DFE to provide methods for job submission, status and progress tracking, etc. | |
Installation management | Nothing special for each individual install | Nothing special for each individual install | Will require editing of configuration files for specific IP addresses/FQDNs. |
Table: HHR scaling models