Hi Bill, Kasun and others, Bill, I think you're explaination does answer one of my questions, and I believe you are correct. During an attach, it is not quite neccessary to merge. +1, for that. This would also save some time on additional processing. However, when we write the element to string, wont this be an additional overhead? If so our payloads are gonna be larger. Thus, we will have to remove redundant namespace declarations at least when we serialize.
Also, copy-on-demand for references are not going to work easily Bill, I believe Kasun explains it better in his latest reply to a child of this thread. When the copying happenps we have already created a web of references, and will be quite complicated to manage. Also we got to think about the time overhead for a single copy operation and redistribution of references, when there are say 10-20 clones of the same sub-tree. Since a clone is an operation on demand and since it is not neccessarily required to be THE BEST method, we can use a serialize/deserialize approach. An advanced user may go ahead and implement his own method for cloning. And, he can expose it through a callback perhaps. Thus, he can write the most efficient solution to suit his local problem rather than we trying to address a global problem. Thus, I'm still +1 on Samisa's cloning using serialize/deserialize as it is the most cleanest approach. Also, Bill that phrase which I quoted was based on a comment that was found in our source. Sorry for any confusions. I noticed it while replying to the JIRA you recently reopened. BTW, It is very nice of you to notice something that we then thought was not required. Regards, Senaka > Senaka, I would like to set aside for a moment the larger issues with > copying that you mention, and just address a couple of your smaller > questions. > > You suggest that when attaching a tree one needs to merge the namespaces. > I don't see why. Certainly, when the detached subtree carries the > references to the namespaces that are used in the tree, when it is > attached to a larger tree and that tree serialized, the namespace > declarations may occur more than once. But this is allowed by the XML > scope rules. Removing the redundant namespace references in some kind of > merge might recreate the very problem that Kasun raises. To be correct > after the merge, every reference to a redundant namespace reference that > was merged would need to be replaced with a pointer to the corresponding > namespace reference in the parent structure that was preserved. > > It is true that the extra namespace declarations may appear unsightly to > the human reader. But they have no impact on an xml parser. Personally, > I'm more concerned that preserving all the namespace prefixes that are > in-scope when the node is detached will retain several prefixes that are > not used in the subtree, e.g., the env prefix for the soap envelope. But, > again, these may be unsightly to the human reader but they have no impact > on an xml parser. > > I don't think I understand your comment about "it is the responsibility of > the person who declares the namespace to free it". Maybe this is a > reference to some earlier discussion. Perhaps this is related to > something strange I see in the code today. The interfaces to > axiom_element_create and axiom_element_set_namespace are a little peculiar > and not consistent. In both, when a namespace is passed, they look to see > if the namespace uri is already declared in a parent, and if so they use > that namespace rather than the one that was passed. In > axiom_element_create, it chooses to free the passed namespace if it was > different from the one it found. This even though the caller will still > have a pointer to the now freed namespace structure. In > axiom_element_set_namespace, it leaves the passed namespace intact, even > though the caller has no way of telling that the namespace was not used in > the element and that the caller needs to free the namespace, creating the > potential for a memory leak. Do you have any idea what the history is > behind these different behaviors? > > Thanks, > Bill > > -----Original Message----- > From: Senaka Fernando [mailto:[EMAIL PROTECTED] > Sent: Friday, February 15, 2008 10:02 AM > To: Apache AXIS C Developers List > Subject: RE: Issue in using 'detach' for cloning > > 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]
