Symbian3/PDK/Source/GUID-C86A7929-DC0F-50FA-93CB-662A22C4CD35.dita
changeset 9 59758314f811
parent 5 f345bda72bc4
child 12 80ef3a206772
--- a/Symbian3/PDK/Source/GUID-C86A7929-DC0F-50FA-93CB-662A22C4CD35.dita	Fri Jun 11 12:39:03 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-C86A7929-DC0F-50FA-93CB-662A22C4CD35.dita	Fri Jun 11 15:24:34 2010 +0100
@@ -1,105 +1,105 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-C86A7929-DC0F-50FA-93CB-662A22C4CD35" xml:lang="en"><title>Device
-Variant Using Multiple Keyspace Files</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>This topic describes the use of multiple keyspace files on multiple ROFS
-layers to create a device variant. </p>
-<section><title>Introduction</title> <p>The central respository consists of
-keyspaces used to store application settings. The device variant creators
-need to modify these settings for every variant of the device. </p> <p>In
-the older method the variant engineer has to branch out the exisiting keyspace
-files , modify the settings and reflash the device with the new keyspace files.
-The disadvantage of the older method is that the variant engineer has to maintain
-multiple keyspace files. The modified keyspace must have the same files name
-as the existing one. </p> </section>
-<section><title>Multiple ROFS layers </title> <p>The central repository now
-supports keyspace that is composed of multiple files. A new keyspace file
-is created for a new ROFS layer. This enables the variant engineers to modify
-a specific setting in the keyspace in one layer and merge the repository with
-the new settings. The new feature to modify specific settings of a keyspace
-reduces the time to create different variants. </p> </section>
-<section><title>Merge the settings</title> <p>The figure below shows how a
-specific setting is modified in the new meachnism. In the example below the
-keyspace d is modified in the new ROFS layer to create a variant. The central
-repository reads the keyspace files and merges the modified settings of <codeph>keyspace
-d</codeph>. The settings in the higher ROFS layer get the priority of the
-settings. The higher ROFS layers cannot modify the global properties of the
-keyspaces like metadata, owner information and the access control information. </p> <fig id="GUID-BABA2027-0E54-575A-8A59-EB771CF46529">
-<title>              Central repository - Modify a setting            </title>
-<image href="GUID-D7179664-C442-5253-9925-994CA0C63B50_d0e590125_href.png" placement="inline"/>
-</fig> <p>The figure below shows how a new setting is added to the central
-repository keyspace. </p> <fig id="GUID-B1ED9F5D-4490-5F61-A084-44C8C6C0978C">
-<title>              Central repository - Add a new setting            </title>
-<image href="GUID-3A07445A-1CD4-5556-BE65-553A4A251789_d0e590136_href.png" placement="inline"/>
-</fig> </section>
-<section><title>Advantages</title> <p>The advantages of using
-multiple ROFS layer to create device variant are: </p> <ul>
-<li id="GUID-EED83088-C966-5206-94B3-4B9B693F6CF7"><p>variant engineers can
-modify selective settings in a keyspace </p> </li>
-<li id="GUID-5FCD32A3-8780-5B5C-BE29-0A6BAA068EF6"><p>no need to branch and
-maintain multiple keyspace files for each variant created </p> </li>
-<li id="GUID-89B96F5E-F33D-5512-889A-98D6A9A35033"><p>central repository can
-detect the multiple keyspace files at run time and merge the settings as one
-keyspace </p> </li>
-</ul> </section>
-<section><title>Guidelines</title> <p>The following are some guidelines to
-use the multiple ROFS layers to create device variant: </p> <ul>
-<li id="GUID-2D54FF98-37FE-554A-9C33-A9E60FFA6EF8"><p>Use the binary files
-(CRE) or text files to initialise the keyspaces </p> </li>
-<li id="GUID-97C5701A-58A5-57FD-A1F6-B36CB169D073"><p>Do not use the combination
-of text and binary files for a keyspace. Use one format of the initialisation
-files. </p> </li>
-<li id="GUID-1A5774F2-9CD9-509C-B17C-83990C51973F"><p>The keyspace files in
-higher ROFS layers must not modify the global properties such as metadata,
-owner information and access control information. </p> </li>
-</ul> </section>
-<section><title>Errors</title> <p>The following table shows the possible errors
-that may occur in use of multiple ROFS layers for device variant creation: </p> <table id="GUID-78196B5E-6474-5C23-9488-10290CA7D3D0">
-<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
-<thead>
-<row>
-<entry>Error</entry>
-<entry>Reason for the error</entry>
-</row>
-</thead>
-<tbody>
-<row>
-<entry><p> <codeph>CENREPCLI: Panic 8</codeph>  </p> </entry>
-<entry><p>The binary files (CRE) must be converted with the new central repository
-conversion tool. </p> </entry>
-</row>
-<row>
-<entry><p> <codeph>CENREPCLI: Panic 9</codeph>  </p> </entry>
-<entry><p>The keyspace files in the higher layer is trying to modify a global
-property </p> </entry>
-</row>
-<row>
-<entry><p> <codeph>CENREPCLI: Panic 10</codeph>  </p> </entry>
-<entry><p>Higher layer keyspace file is trying to modify a type of a setting
-in the lower layer </p> </entry>
-</row>
-<row>
-<entry><p> <codeph>CENREPCLI: Panic 11</codeph>  </p> </entry>
-<entry><p>The default ROFS layer file is associated with <codeph>exattrib=u
-                  </codeph> attribute </p> </entry>
-</row>
-</tbody>
-</tgroup>
-</table> </section>
-</conbody><related-links>
-<link href="GUID-E3BE62B2-9625-5F79-84A4-0248A3F36225.dita"><linktext> Central
-Repository Access Guide</linktext></link>
-<link href="GUID-1C683226-C142-5C7B-BD20-060058352B08.dita"><linktext>Central Repository
-Guide </linktext></link>
-<link href="GUID-3D152CC5-AF20-520A-AB67-457F956A5551.dita"><linktext>Device Variant
-With Multiple ROFS Layers                 Tutorial </linktext></link>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-C86A7929-DC0F-50FA-93CB-662A22C4CD35" xml:lang="en"><title>Device
+Variant Using Multiple Keyspace Files</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>This topic describes the use of multiple keyspace files on multiple ROFS
+layers to create a device variant. </p>
+<section><title>Introduction</title> <p>The central respository consists of
+keyspaces used to store application settings. The device variant creators
+need to modify these settings for every variant of the device. </p> <p>In
+the older method the variant engineer has to branch out the exisiting keyspace
+files , modify the settings and reflash the device with the new keyspace files.
+The disadvantage of the older method is that the variant engineer has to maintain
+multiple keyspace files. The modified keyspace must have the same files name
+as the existing one. </p> </section>
+<section><title>Multiple ROFS layers </title> <p>The central repository now
+supports keyspace that is composed of multiple files. A new keyspace file
+is created for a new ROFS layer. This enables the variant engineers to modify
+a specific setting in the keyspace in one layer and merge the repository with
+the new settings. The new feature to modify specific settings of a keyspace
+reduces the time to create different variants. </p> </section>
+<section><title>Merge the settings</title> <p>The figure below shows how a
+specific setting is modified in the new meachnism. In the example below the
+keyspace d is modified in the new ROFS layer to create a variant. The central
+repository reads the keyspace files and merges the modified settings of <codeph>keyspace
+d</codeph>. The settings in the higher ROFS layer get the priority of the
+settings. The higher ROFS layers cannot modify the global properties of the
+keyspaces like metadata, owner information and the access control information. </p> <fig id="GUID-BABA2027-0E54-575A-8A59-EB771CF46529">
+<title>              Central repository - Modify a setting            </title>
+<image href="GUID-D7179664-C442-5253-9925-994CA0C63B50_d0e577831_href.png" placement="inline"/>
+</fig> <p>The figure below shows how a new setting is added to the central
+repository keyspace. </p> <fig id="GUID-B1ED9F5D-4490-5F61-A084-44C8C6C0978C">
+<title>              Central repository - Add a new setting            </title>
+<image href="GUID-3A07445A-1CD4-5556-BE65-553A4A251789_d0e577842_href.png" placement="inline"/>
+</fig> </section>
+<section><title>Advantages</title> <p>The advantages of using
+multiple ROFS layer to create device variant are: </p> <ul>
+<li id="GUID-EED83088-C966-5206-94B3-4B9B693F6CF7"><p>variant engineers can
+modify selective settings in a keyspace </p> </li>
+<li id="GUID-5FCD32A3-8780-5B5C-BE29-0A6BAA068EF6"><p>no need to branch and
+maintain multiple keyspace files for each variant created </p> </li>
+<li id="GUID-89B96F5E-F33D-5512-889A-98D6A9A35033"><p>central repository can
+detect the multiple keyspace files at run time and merge the settings as one
+keyspace </p> </li>
+</ul> </section>
+<section><title>Guidelines</title> <p>The following are some guidelines to
+use the multiple ROFS layers to create device variant: </p> <ul>
+<li id="GUID-2D54FF98-37FE-554A-9C33-A9E60FFA6EF8"><p>Use the binary files
+(CRE) or text files to initialise the keyspaces </p> </li>
+<li id="GUID-97C5701A-58A5-57FD-A1F6-B36CB169D073"><p>Do not use the combination
+of text and binary files for a keyspace. Use one format of the initialisation
+files. </p> </li>
+<li id="GUID-1A5774F2-9CD9-509C-B17C-83990C51973F"><p>The keyspace files in
+higher ROFS layers must not modify the global properties such as metadata,
+owner information and access control information. </p> </li>
+</ul> </section>
+<section><title>Errors</title> <p>The following table shows the possible errors
+that may occur in use of multiple ROFS layers for device variant creation: </p> <table id="GUID-78196B5E-6474-5C23-9488-10290CA7D3D0">
+<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
+<thead>
+<row>
+<entry>Error</entry>
+<entry>Reason for the error</entry>
+</row>
+</thead>
+<tbody>
+<row>
+<entry><p> <codeph>CENREPCLI: Panic 8</codeph>  </p> </entry>
+<entry><p>The binary files (CRE) must be converted with the new central repository
+conversion tool. </p> </entry>
+</row>
+<row>
+<entry><p> <codeph>CENREPCLI: Panic 9</codeph>  </p> </entry>
+<entry><p>The keyspace files in the higher layer is trying to modify a global
+property </p> </entry>
+</row>
+<row>
+<entry><p> <codeph>CENREPCLI: Panic 10</codeph>  </p> </entry>
+<entry><p>Higher layer keyspace file is trying to modify a type of a setting
+in the lower layer </p> </entry>
+</row>
+<row>
+<entry><p> <codeph>CENREPCLI: Panic 11</codeph>  </p> </entry>
+<entry><p>The default ROFS layer file is associated with <codeph>exattrib=u
+                  </codeph> attribute </p> </entry>
+</row>
+</tbody>
+</tgroup>
+</table> </section>
+</conbody><related-links>
+<link href="GUID-E3BE62B2-9625-5F79-84A4-0248A3F36225.dita"><linktext> Central
+Repository Access Guide</linktext></link>
+<link href="GUID-1C683226-C142-5C7B-BD20-060058352B08.dita"><linktext>Central Repository
+Guide </linktext></link>
+<link href="GUID-3D152CC5-AF20-520A-AB67-457F956A5551.dita"><linktext>Device Variant
+With Multiple ROFS Layers                 Tutorial </linktext></link>
 </related-links></concept>
\ No newline at end of file