Guidelines for Kaltura CMS Extensions Development

This document discusses guidelines and best practices for Kaltura CMS Extension development.

Installation support for both SaaS and Kaltura CE

Targeting both platform editions is easy since the APIs are the same. however, minor modifications may be required for self-hosted CE servers.

Use the following best practice script for creating the installation process for your extensions: http://apis.kaltura.org/kalturaJsClient/kaltura-register.html
The registration link uses the Kaltura JavaScript client library and does not require additional server modifications, it is suggested the same flow and fields will be used when creating a Kaltura registration form.

In order to track the usage and installation of users that installed your extension, modify the script and change the value of the following hidden field to the name of your extension:
<input type="hidden" value="Your ext" name="campaign" id="campaign" />

Register users to Kaltura in installation flow

This will simplify the installation workflow and the work with the system.
Register page should confirm to Kaltura standard registration form (see: http://corp.kaltura.com/about/signup)
and include all the following fields:

Send Heartbeat

Send a Heartbeat from the extension to Kaltura.org. This is required for statistics reasons, for every extension we will present the number of active installations as part of Kaltura.org.
Heartbeat must confront to the following API – Currently under development.

Recommended Practice

The following are recommendations, build the experience gathered from the community and internal development processes:

Allow publisher to import content from existing account

If the publisher already has an account with Kaltura, during installation process it is recommended to allow him to import the content from this account (see Drupal module installation flow)

Support native upgrade process

Most frameworks have a built-in process for extension upgrades. Please follow those guidelines and expose extension version in UI.

Support player selection

Supporting players created in Application studio will allow flexibility to the publisher. The selection can be across all players, or per specific content item.

The “Create a new player” will lead to the KMC to the application studio tab.
The player width and height should be taken from the content being played or defined by the user on the form to allow manual change.
The size settings should be saved so that next time the user will not have to enter the values again.
For a JavaScript sample code showing how to pull all the widgets a partner has in his Kaltura account (including custom players created in Application Studio) visit:
http://apis.kaltura.org/kalturaJsClient/jsClientPlayground.php (Details and source available in the Kaltura JavaScript Client Library project).

Support Content upload widget selection (Settings panel)

In many cases the site developer would like to differentiate between usecases of adding video, images and audio. A simple solution for that would be creating several UIConfs to be selected by the user:

• CW only video
• CW only images
• CW only audio
• CW only documents
• CW all
• KSU - to avoid long loading time of flash, use the KSU widget and implement an HTML UI.
• Custom UIConfID – to allow Projects team to create special UI confs for the user.
  A drop-down box on the extension settings panel can be used to select the type of the default KCW to use, for example:

If selecting custom UI conf instead of the drop-down, the user should enter his KCW uiConf into an input text field.

The content upload widget (whether KCW or KSU) should feature a “My Content” tab allowing the user to search for his own uploaded content:

Maintain cross-edition compatibility - Do not hard-code ids and urls

When creating your extension, make sure all urls and ids are easily configured.
The Kaltura server can be installed on any domain or the services can be used from the Kaltura SaaS via kaltura.com. Moreover, the uiConf ids on the various servers can be different.
Thus, make sure that any uiConf ids for players and editors are easily configured via the extension GUI or at least using a centralized configuration file. Additionally, make sure the server url is not hard-coded either.
This will make sure your extension will be easily configured to use a self hosted Kaltura server and the SaaS on kaltura.com.