--- a/Symbian3/PDK/Source/GUID-A8EADD99-561C-5077-834F-DFC2CC4AE6E2.dita	Thu Mar 11 15:24:26 2010 +0000
+++ b/Symbian3/PDK/Source/GUID-A8EADD99-561C-5077-834F-DFC2CC4AE6E2.dita	Thu Mar 11 18:02:22 2010 +0000
@@ -1,12 +1,12 @@
-<?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">
+<?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 xml:lang="en" id="GUID-A8EADD99-561C-5077-834F-DFC2CC4AE6E2"><title>Copying</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>When a container object has been edited, but some of its component objects have not been changed, it is desirable to be able to copy the component object, or a reference to it, without first restoring that object into memory and then storing it back again. There are many motivations for this:</p> <ul><li id="GUID-7B627D93-02CC-5420-9E99-469D450322C5"><p>space requirement: in most contexts, both the external representation of the component object (in a file) and its internal representation use RAM space. Restoring an object from a file generates a second instance of it; storing it back into another file generates a third instance, before the first file and the internal representation can be deleted. This triplication of space requirement is especially undesirable for large objects.</p> </li> <li id="GUID-C8FF1473-6A29-59B2-B497-0B4318D681A2"><p>generality: it is desirable to be able to copy an object without knowing its detail, e.g. which program created it.</p> </li> <li id="GUID-0176016A-090E-58BA-9178-6AFF779B437B"><p>security: if an object is password protected, it cannot be opened without specifying a password. It is undesirable to have to specify a password to copy an embedded object, especially if the only requirement is to edit that object's container.</p> </li> </ul> <p>There are two main cases:</p> <ul><li id="GUID-45E6CC23-B06A-5635-A2E5-784B58DACDAF"><p>with a direct file store, the component object data must be copied from one store to another without internalizing it: this is achieved by copying the streams directly, and this itself is only possible because of embedded stores </p> </li> <li id="GUID-3DE700D1-D34B-5C87-A9A6-3608A21303CE"><p>with a permanent file store, the component object can be left in place, and just its stream id re-used: this is achieved by copying the Swizzle, and is provided by store map functions</p> </li> </ul> </conbody></concept>
\ No newline at end of file