Federated Search – Indexing Module Terminology

  • Seed – An authenticated, enriched MRSS feed containing ALL non-private portal content. Used by the index developers the first time they incorporate content from the portal. Traditionally, federated search integrations would come up when there is already a substantial amount of content in the portal. The developer would therefore need to first index all existing (non-private) content, and moving forward will use the Sync feed (see below) to periodically ping the portal for updates. Due to the expected large volume of content in the Seed feed, a paging mechanism is provided.

  • Sync - An authenticated, enriched MRSS feed containing all recent changes to non-private portal content since last ping. The Sync feed will also include entries deleted since last ping. The Sync feed cannot reference entries turned private again (un-published). It is therefore recommended that the Seed feed is pinged again, in low-frequency (once a quarter) to perform periodic index cleanup of indexed entries which no longer appear in the Seed.

  • App Token – a context-specific API token for accessing a Kaltura account via API. By “context-specific” we mean that, unlike the “admin secret” and “user secret” available to Kaltura super-admins (via the KMC), serving as “keys to the kingdom”, App Tokens:
    1. Are limited regarding the API services they can access,
    2. Are limited regarding the content they can access,
    3. Can be revoked.

These attributes make App Tokens a great fit for Federated Search projects, allowing the Kaltura main customer, often the video portal admin or KMC admin, to:

    • stay in control of their “kingdom” without ever sharing their admin secrets, 
    • grant business-unit developers limited API access for their own projects,
    • always have the option to revoke such access if/when needed.

      The Federatedserachindexing module allows the admin to generate an App Token with a single click, no coding required, and simply provide the App Token information (iId and value) to the developer. More technical (portal admins can skip this part) background on App Tokens is available on the Kaltura Developers Portal, here.
  • KS – Kaltura Session. A time-limited API session created using the App Token. Provides authentication for loading content from any of the feeds.

  • XSLT – A transformation file. Used to transform the feeds’ structure to meet requirements of specific 3rd party search engines. If there is a requirement to comply with a specific feed structure, the module allows the admin to download the current transformation file and provide it to the developer for modification. The developer would then modify the XSLT to generate a feed in the specific structure required, and return the file to the admin, who will then upload the revised file.
    NOTE: This will automatically regenerate both sync and seed feeds.

Federated Search is designed with developers in mind. Authenticating using an App Token is the only Kaltura API ramp up required by the developer when building a Consumer. The rest of the work is accomplished using standard MRSS conventions. To make ramp up even easier, Kaltura provides an interactive code recipe tutorial on how to authenticate using App Tokens, in all major coding languages.The code recipe can be accessed here.

Back to Federated Search Indexing Module

In This Article
Was this article helpful?
Thank you for your feedback!