Apparc -Recognizer for CAF

The Apparc framework uses data type recognizers derived from CApaDataRecognizerType to -determine the MIME type of files on the Symbian platform.

Overview

Apparc supplies the filename and a buffer -containing bytes read from the start of the file. If a file is recognized, -the recognizer must return the MIME type and the degree of confidence in recognizing -the file — a TInt ranging from KMinInt (Not -Recognized) to KMaxInt (Certain).

The implementation -of DRM has a problem when determining the MIME type. A DRM file stores one -or more content objects. For example, an OMA file with MIME type application/vnd.oma.drm.content may -store an image file with MIME type image/jpeg. Apparc expects -only one MIME type to be returned, not two.

The CAF recognizer RECCAF.DLL determines -whether a file is recognized by CAF and if so, retrieves these two MIME types.

The -mapping of these two MIME types returned by CAF to a single MIME type is based -on the following rules:

- - - -

File MIME type

Content MIME type

Apparc MIME type

- - -

Present

x-caf- ContentMimeType

- - -

Present

Not Present

FileMimeType

- - -

Present

application/x-caf

- - - -

The following is the rationale for the above mapping:

The x-caf- prefix -to the content type shows that the file that can be opened by CAF to read -that content type.
A file that needs to -be passed through the supplier interface before it can be used is recognized -as the file MIME type; the content type is irrelevant before the supply operation.
A file containing many -content objects must just be recognized as application/x-caf as -the packaging of the archive is irrelevant (CAF abstracts the packaging).

The following diagram illustrates the recognition of an OMA file -with JPEG content.

- Apparc Recognizer for CAF - -

Application registration files

To use CAF content, -applications must update their registration resource files (for example AppName_reg.rss) -to include the new CAF MIME types. For example, an image viewer may have only -included image/jpeg in the list of MIME types it could open. -If the application is updated to use CAF, it must support image/jpeg and x-caf-image/jpeg in -order to support unprotected and protected content respectively. See the following -example registration file.

All file operations must be conducted through -the CAF framework.

Registration file that does not use CAF

... - -datatype_list = - { - DATATYPE { priority= EDataTypePriorityHigh ; type="image/jpeg";}, - } - -...

Registration file that use CAF

... - -datatype_list = - { - DATATYPE { priority= EDataTypePriorityHigh ; type="image/jpeg"; }, - - DATATYPE { priority= EDataTypePriorityHigh ; type="x-caf-image/jpeg"; }, - } - -...

+ + + + + +Apparc +Recognizer for CAF +

The Apparc framework uses data type recognizers derived from CApaDataRecognizerType to +determine the MIME type of files on the Symbian platform.

Overview

Apparc supplies the filename and a buffer +containing bytes read from the start of the file. If a file is recognized, +the recognizer must return the MIME type and the degree of confidence in recognizing +the file — a TInt ranging from KMinInt (Not +Recognized) to KMaxInt (Certain).

The implementation +of DRM has a problem when determining the MIME type. A DRM file stores one +or more content objects. For example, an OMA file with MIME type application/vnd.oma.drm.content may +store an image file with MIME type image/jpeg. Apparc expects +only one MIME type to be returned, not two.

The CAF recognizer RECCAF.DLL determines +whether a file is recognized by CAF and if so, retrieves these two MIME types.

The +mapping of these two MIME types returned by CAF to a single MIME type is based +on the following rules:

+ + + +

File MIME type

Content MIME type

Apparc MIME type

+ + +

Present

x-caf- ContentMimeType

+ + +

Present

Not Present

FileMimeType

+ + +

Present

application/x-caf

+ + + +

The following is the rationale for the above mapping:

The x-caf- prefix +to the content type shows that the file that can be opened by CAF to read +that content type.
A file that needs to +be passed through the supplier interface before it can be used is recognized +as the file MIME type; the content type is irrelevant before the supply operation.
A file containing many +content objects must just be recognized as application/x-caf as +the packaging of the archive is irrelevant (CAF abstracts the packaging).

The following diagram illustrates the recognition of an OMA file +with JPEG content.

+ Apparc Recognizer for CAF + +

Application registration files

To use CAF content, +applications must update their registration resource files (for example AppName_reg.rss) +to include the new CAF MIME types. For example, an image viewer may have only +included image/jpeg in the list of MIME types it could open. +If the application is updated to use CAF, it must support image/jpeg and x-caf-image/jpeg in +order to support unprotected and protected content respectively. See the following +example registration file.

All file operations must be conducted through +the CAF framework.

Registration file that does not use CAF

... + +datatype_list = + { + DATATYPE { priority= EDataTypePriorityHigh ; type="image/jpeg";}, + } + +...

Registration file that use CAF

... + +datatype_list = + { + DATATYPE { priority= EDataTypePriorityHigh ; type="image/jpeg"; }, + + DATATYPE { priority= EDataTypePriorityHigh ; type="x-caf-image/jpeg"; }, + } + +...

\ No newline at end of file