Symbian
Symbian Developer Library

SYMBIAN OS V9.4

Feedback

[Index] [Previous] [Next]


Introduction

[Top]


Status

The Content Access Framework is at released status in Symbian OS v9.1.

[Top]


Overview

The Symbian OS Content Access Framework (CAF) provides services that enable agents to publish content in a generic manner that is easy for applications to use.

Applications will access content the same way regardless of whether the content is plain text, located in a server's private directory, or DRM protected.

Content can be, for example, media files or a level in a game; applications would be, for example, a video/sound player or an internet browser; DRM stands for Digital Rights Management.

[Top]


CAF agents

The CAF defines an ECom plug-in interface, for third-party CAF agents. The interface allows new agents to be integrated at a later date, dynamically if required. The specification for this interface can be found in ContentAccess::CAgentFactory.

CAF agents can be written to provide the following functions:

The CAF framework does not provide any capability enforcement so it is the responsiblity of the agent to police access to the APIs. The agent can choose to deny some operations in the CAF API based upon application's capabilities or the agent's own policy relating to the use of that API.

[Top]


Agent interfaces

A CAF agent must implement a concrete factory derived from ContentAccess::CAgentFactory. This is the ECom interface for a CAF Agent.

The agent's factory will produce products derived from:

These products provide the services described in the introduction (above) on a per agent basis.

[Top]


Content Access Framework APIs

Generally, these APIs fall into four areas:

Supplier API

The Supplier API is used to handle the delivery and transformation of content. It can be used to transform DRM protected files when they arrive on a device into a form that allows them to be stored securely on the device.

It can also be used intercept content and ensure it is stored in an agent's private directory.

See the classes ContentAccess::CSupplier and ContentAccess::CImportFile.

Consumer API

Allows applications to read the content as if it were stored as plain text regardless of how it is actually stored on the device. For instance, it might be encrypted.

The consumer API will be used by applications rendering content and/or multimedia plug-ins. By rendering we mean reading data from a file, transforming it, then playing or displaying it on the device.

See the classes ContentAccess::CContent and ContentAccess::CData.

Manager API

The management of files and content access agents.

See ContentAccess::CManager.

Rights Manager API

A generic API used to manage DRM rights within a particular DRM agent.

See ContentAccess::CRightsManager.

[Top]


Access to content within archive files

An archive file contains content objects and other containers within the file. Each container within the file may contain more content objects or further containers. Common examples of archive files are zip and tar files.

The Content Access Framework allows applications to open archive files and read content from inside them. The content objects and containers inside the file can be traversed using the ContentAccess::CContent class.

This class allows applications to use the content within these container files without needing to understand any specifics of the compression or storage mechanism used by the archive.

[Top]


Digital Rights Management (DRM)

The Content Access Framework also provides an abstract way to access DRM protected content. An agent can be designed to implement a DRM scheme.

Applications use DRM protected files in the same way they would use any other file. The agent enforces the rights applied to the content. Also, it prevents access when rights have expired or if the file is accessed by applications without DRM capability.

To enforce the protection of the content, the agent must know what the client intends to do with the content once it has read the plain-text version of that content. Therefore, applications must specify their intent before using DRM protected content, see DRM Intent.

Applications should always specify their intent, whether or not they will be using DRM protected content. Non-DRM agents will just ignore the call, but it means the application does not need to treat DRM content as a special case.

One occasion when applications do need to treat DRM as a special case is where User Interface menu items may need to be disabled. For example, when save or send via Bluetooth may not be permitted. Applications can use the GetAttribute() functions to determine whether the operation is allowed on any given content object.

Finally, any application or plug-in that reads DRM content must handle the unencrypted version of the content responsibly. Only applications proven to work this way will be given the DRM capability.

[Top]


DRM intent

The evaluation of DRM rights hinges on the correct supply of 'DRM Intent' from the trusted rendering application to the Content Access Framework. The framework provides a number of options so that the application can query and evaluate rights appropriately.

Briefly, the CAF allows a renderer to:

Essentially, renders will begin by evaluating intent when the CData object is created. When the content has been rendered successfully, they will execute the intent to ensure that stateful rights are then processed.

The recommended intent values (for renders and agents to support) are given in ContentAccess::TIntent:

[Top]


The F32 agent

The F32 agent provides access to unprotected files. It is really just a wrapper around RFile. The Content Access Framework treats the F32 agent as a special case. If no other suitable agent is responsible for a file or directory, the F32 Agent will be used.

The F32 agent runs in the same process and thread as the calling application so any file operations it performs will be limited to the file operations permitted for the calling application's process.

[Top]


Sharing content in a private directory

Some agents may provide access to files stored in their private directory. They can advertise the files' existence to applications through their implementation of the ContentAccess::CAgentManager::GetDir() function.

In the file system the private directories have the format:

\private\xxxxxxxx\directory_1\...directory_n\filename.ext

where xxxxxxxx is the UID of the agent.

CAF will translate that path so applications see the file as:

\private\agent_name\directory_1\...directory_n\filename.ext

where agent_name is the name of the agent.

When an application opens a file stored in the private directory, CAF selects the agent which handles that content based upon the name in the path. If the file is not stored in a private directory, CAF asks each of the agents in turn whether they support the file. If no agent supports the file, it will be read as plaintext using the F32Agent.

[Top]


Delivery