os/security/contentmgmt/contentaccessfwfordrm/engineering/dox/NavigatingArchiveFiles.dox
author sl@SLION-WIN7.fritz.box
Fri, 15 Jun 2012 03:10:57 +0200
changeset 0 bde4ae8d615e
permissions -rw-r--r--
First public contribution.
sl@0
     1
// Copyright (c) 2006-2009 Nokia Corporation and/or its subsidiary(-ies).
sl@0
     2
// All rights reserved.
sl@0
     3
// This component and the accompanying materials are made available
sl@0
     4
// under the terms of the License "Eclipse Public License v1.0"
sl@0
     5
// which accompanies this distribution, and is available
sl@0
     6
// at the URL "http://www.eclipse.org/legal/epl-v10.html".
sl@0
     7
//
sl@0
     8
// Initial Contributors:
sl@0
     9
// Nokia Corporation - initial contribution.
sl@0
    10
//
sl@0
    11
// Contributors:
sl@0
    12
//
sl@0
    13
// Description:
sl@0
    14
// An application can explore the content objects inside a file using the <code>ContentAccess::CContent</code> class.
sl@0
    15
// <hr>
sl@0
    16
// The Content Access Framework provides a generic mechanism for exploring files that contain multiple
sl@0
    17
// content objects. These files are often referred to as archive files. This could
sl@0
    18
// be anything from a .ZIP compression archive to a DRM protected archive such as an OMA .DCF file.
sl@0
    19
// Inside an archive file, and in addition to the content objects, there will be meta-data or information 
sl@0
    20
// associated with the content. This meta-data could include information such as the MIME type of the content, 
sl@0
    21
// encryption algorithm, compressed size of the content etc.. This information can be retrieved from the attributes
sl@0
    22
// The content and meta-data may also be arranged in a heirachy with container objects grouping 
sl@0
    23
// content objects together. A typical archive could have a complex structure like the example shown below:
sl@0
    24
// In this situation the file itself can be considered as the top level container. All other content, containers and
sl@0
    25
// meta-data are nested inside. 
sl@0
    26
// In an archive file applications can quickly search for the content objects they are interested in by using 
sl@0
    27
// <code>ContentAccess::CContent::Search()</code>.
sl@0
    28
// <hr>
sl@0
    29
// Archive files containing several content objects cannot be referred to using just the URI of the file. The Content Access
sl@0
    30
// Framework uses a concept of virtual paths to identify content objects within a file. The virtual path is a combination
sl@0
    31
// of the file URI and a unique identifier supplied by the agent: 
sl@0
    32
// A content file is only ever handled by the agent that recognises it. The unique identifier will never need to be 
sl@0
    33
// decoded by anyone other that the agent that generated it, so the format is left for the agent to implement as it sees
sl@0
    34
// fit. For instance an OMA DRM agent may put the Content ID (CID) in the \c UniqueId field.
sl@0
    35
// The only constraint is that the \c UniqueId must be unique within the file. An application must be able to directly
sl@0
    36
// reference a content object just using the <code>UniqueId</code>. 
sl@0
    37
// <hr>
sl@0
    38
// <b> Virtual Path pointer objects on the Stack </b>
sl@0
    39
// The <code>ContentAccess::TVirtualPathPtr</code> is used to point to two descriptors holding the URI 
sl@0
    40
// of a file and the <code>UniqueId</code> of a content object within the file. It can also be used to 
sl@0
    41
// point to another <code>TVirtualPathPtr</code>. Since it is only a pointer, the original descriptors 
sl@0
    42
// used to initalise the <code>TVirtualPathPtr</code> should not be destroyed or modified while the 
sl@0
    43
// <code>TVirtualPathPtr</code> is still in use.
sl@0
    44
// <b> Virtual Path objects on the heap </b>
sl@0
    45
// The <code>ContentAccess::CVirtualPath</code> class stores the file URI and content object <code>UniqueId</code> in its own 
sl@0
    46
// descriptors. There is a cast operator that allows the <code>CVirtualPath</code> to be used as 
sl@0
    47
// if it were a <code>TVirtualPathPtr</code>.
sl@0
    48
// <b> Examples </b>
sl@0
    49
// // Open a CContent object to browse the objects inside a file
sl@0
    50
// CContent *c = CContent::NewL(_L("C:\file.dcf"));
sl@0
    51
// CleanupStack::PushL(c);
sl@0
    52
// // Create an array to store the embedded objects
sl@0
    53
// RStreamablePtrArray<CEmbeddedObject> myArray;
sl@0
    54
// CleanupClosePushL(myArray);
sl@0
    55
// // Get an array of the embedded objects within the current container in the file
sl@0
    56
// c->GetEmbeddedObjectsL(myArray);
sl@0
    57
// // If necessary we can get a "mangled" version of the URI that 
sl@0
    58
// // references the particular object within the file
sl@0
    59
// // ie. "C:\file.dcf\\OBJECT1"
sl@0
    60
// TPtrC aURI = *myArray[0];
sl@0
    61
// // Now we can use our TPtrC later to create a TVirtualPath object from a URI
sl@0
    62
// TVirtualPathPtr aPtr = aURI;
sl@0
    63
// // print the file URI  "C:\file.dcf"
sl@0
    64
// printf(aPtr.URI());
sl@0
    65
// // print the content object's UniqueId "OBJECT1"
sl@0
    66
// printf(aPtr.UniqueId());
sl@0
    67
// // Create a copy of aVirtualPath on the heap so we don't have any ownership problems
sl@0
    68
// CVirtualPath *myVirtualpath = CVirtualPath::NewL(aPtr);
sl@0
    69
// // Can now delete the CContent object without loosing our VirtualPath
sl@0
    70
// CleanupStack::PopAndDestroy(2);	// c, myArray
sl@0
    71
// <hr>
sl@0
    72
// <b><code>KNullDesC16() -  ""</code></b>
sl@0
    73
// A zero length \c UniqueId is used to refer to the entire file. If a file is opened this way no translation of the contents will be
sl@0
    74
// performed. The ability to open the file with no translation is required for example to attach the file to an outgoing message.
sl@0
    75
// As with any other function in CAF access to the file is at the agents discretion.
sl@0
    76
// <b><code>KDefaultContentObject() - "DEFAULT"</code></b>
sl@0
    77
// Allows an application to refer to the default content object within a file. In the case of an unprotected file handled
sl@0
    78
// by the \c F32Agent this will be the entire file, the same as if the <code>UniqueId ""</code> was used. Other agents, particularly those
sl@0
    79
// with a single content object embedded within the file, use <code>"DEFAULT"</code> to refer to their only content object.
sl@0
    80
// Even though the DEFAULT content object is supported, it is recommended that agents always use \c CContent to enumerate the 
sl@0
    81
// objects within the file.
sl@0
    82
// <hr>
sl@0
    83
// 
sl@0
    84
//
sl@0
    85
sl@0
    86
/**
sl@0
    87
 @page FileOverview Files containing multiple content objects 
sl@0
    88
 - @ref FileOverviewDescription
sl@0
    89
 - @ref VirtualPaths
sl@0
    90
 - @ref VirtualPathObjects
sl@0
    91
 - @ref SpecialUniqueIds
sl@0
    92
 @section FileOverviewDescription Structure of a file containing multiple content objects
sl@0
    93
 related to a content object, see @ref ContentAttributes "Content Object Attributes".
sl@0
    94
 @image html "multiple DRM file2.gif"
sl@0
    95
 @section VirtualPaths Identifying a content object within a File
sl@0
    96
 @li \c URI      - The location of the file
sl@0
    97
 @li \c UniqueId - The content object inside the file.
sl@0
    98
 @section VirtualPathObjects Objects used to identify a content object within a File
sl@0
    99
 @code
sl@0
   100
 @endcode
sl@0
   101
 @section SpecialUniqueIds Special Cases for the UniqueId field
sl@0
   102
*/