Hi All, As far as I can see there is a problem with ref counts based cloning that is very hard to solve. Let's say we clone a node 5 times and we have six node trees. The cloned node trees will be pointing to the original node tree for some structures like namespaces. When we needs to modify something in a cloned tree we know that we are pointing to another structure in the original tree and we can take appropriate actions like creating a new structure (copy on write).
But Interesting thing is what happens when we need to change the original node tree. Then we will have to create 5 structures for the cloned trees and attach them to those trees. But just by looking at the original node tree we cannot say who are pointing to the original node tree. So we have to keep tack of the cloned node trees in the original node tree as well. This is very hard to do if it not impossible. Onother issue is what happens when we clone the cloned tree? Regards, Supun.. On 2/15/08, Senaka Fernando <[EMAIL PROTECTED]> wrote: > Hi, > > A locally viable solution wouldn't solve all the issues with cloning Bill. > Once we have this feature added, we'll simply have to address a new set of > client requests bugs etc. coming after that. I believe this is viable at > Kasun's end, but, not in Axis2/C. We have to figure out how to do these > after cloning. > > 1. Rename/Delete namespaces > 2. Add new namespaces and re-attach to original tree. > 3. Add new namespace with same prefix but different uri to original sub tree. > > How are these possible? > > If you use detach, you have one big ease. That is, you only got to worry > about namespaces. If you go for clone, you also got to worry about > attributes etc. Thus, clone will be a deep copy of all references, and a > serialize/de-serialize would be rather efficient than seeking and > duplicating. At least because it all happens if one step without > conditional expression evaluation. But, in the case of a detach you will > rather only need to bother about namespaces which in return would be > deep-copies. Also if you plan to add an attach method, you will have to > merge child's namespaces into the parent through a comparison. > > I have great deal of doubt about shallow copies. Mainly because I remember > seeing something like, "it is the responsibility of the person who > declares the namespace to free it", which violates the whole idea. > > > Please correct me if I'm wrong. > > Regards, > > Senaka > > > > Samisa, I think what Kasun was saying is that detach, if it did not lose > > the namespace references for the attributes, does work for him. When he > > attaches the detached tree into a new larger tree, the detached tree needs > > to keep valid namespace references for all of its nodes, even when the > > parent node, Node A, does not already refer to those same namespaces. > > > > I presume, as well, if he needs to include the detached subtree into > > several trees, a shallow copy works, as it preserves the information. > > > > Regards, > > Bill > > > > -----Original Message----- > > From: Samisa Abeysinghe [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 15, 2008 4:42 AM > > To: Apache AXIS C Developers List > > Subject: Re: Issue in using 'detach' for cloning > > > > Kasun Indrasiri wrote: > >> > >> > >> On 2/15/08, *Samisa Abeysinghe* <[EMAIL PROTECTED] > >> <mailto:[EMAIL PROTECTED]>> wrote: > >> > >> > >> Once you detach, how are you going to use the detached node? Attach > >> to > >> another tree? > >> > >> > >> Samisa... > >> > >> > >> Hi, > >> After detaching the node from the original node, the detached node is > >> attached to another node (say node A) as a child node. Node A, > >> may or may not have the namespaces used in the detached node. > > > > OK, so current detach does not work for you. Would serialize sub tree > > and then deserialize would be a viable option for you? > > > > Samisa... > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
