axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Issue in using 'detach' for cloning
Date Thu, 01 Jan 1970 00:00:00 GMT
Dinesh, you are right that one can develop a cloning algorithm that defers any copying until
the object is modified, a copy-on-write algorithm.  But such an algorithm would depend on
knowing that ref counts are used only for cloning.  Given this assumption, when the ref count
was greater than one, the code could choose to copy an instantiate a new instance of the object
when it was modified.  

I don't think that assumption is met today.  I see ref counts implemented currently for attributes
and namespaces, and not for elements or text.  In particular, for attributes, this allows
the user of axiom to create an attribute one time, and attach it to several elements as needed.
 And it could be that this user wants the ability to change the attribute value once and have
the modification apply to all the elements that share it.  

Now maybe this is a capability that was not foreseen and is not supported, but it exists nonetheless.
 So one cannot implement a copy-on-write algorithm without risking breaking existing code.

Of course, such a tree causes problems for any cloning algorithm.  A serialize/deserialize
clone cannot preserve this intentional shared use of an object.  But I would hate to see a
cloning algorithm that might be useful for many folks break some other existing use of axiom.

I happened to take advantage of these ref counts to simplify and make more efficient the process
of copying a tree, by sharing the attributes instead of creating new copies.  But it is certainly
something that should be done only if documented so that the user of the method understands
the implication that modifications to an attribute value, without removing and creating a
new attribute, would change its values for multiple trees.  I found such a copy very useful
in taking responses from SOAP messages that I needed to modify and include in later SOAP requests.
 But I understand that some people might feel queasy about such a shallow copy.    


-----Original Message-----
From: Dinesh Premalal [] On Behalf Of Dinesh Premalal
Sent: Friday, February 15, 2008 2:44 AM
Subject: Re: Issue in using 'detach' for cloning

Hi Bill, Samisa,
Samisa Abeysinghe <> writes:
>> So I'm beginning to think there should be two functions, one is a
>> shallow copy of all the data elements and text values, sharing the
>> attributes and namespaces, the second is a true clone of all the
>> structures throughout the tree.  And certainly you are right that
>> the easiest way to implement clone as a deep copy is to serialize
>> the tree and deserialize it into a new structure.    
> I agree with you 100%. With ref counts, what we effectively have is a
> shallow copy, and that would work, as ling as the two "virtual" copies
> are supposed to be identical. If in any case, one wants to modify one
> tree independent of the other, then the shallow copy with ref counts
> would not work, in which case you can look to the alternative of
> serilizing and deserializing for a deep copy.

Though Bill's ref count solution sounds bit complex, I like that
suggestion. Because it's efficient than serialize and deserialize
solution that Samisa suggest. As Samisa pointed out, It seems that ref
count solution doesn't stand for when someone needs to change modify
one tree independent of the other.

We can have two"virtual" copies as long as they are identical. When
user needs to modify one tree , can't we make copy of that tree and
allow him to modify. This will explain it clearly [1]. To be clear on
what I mean here,  

Say that user have detach node and original node. AFAIU, According to
ref count solution , detach node still pointing to original node's
namespaces and attributes (with increased ref counts). When user going
to make a modification to an attribute in detach node, simply we can't
let to modify original tree's attribute. Instead we could make a copy
of original tree's attribute and let the user to change it. 

If we handle this way, we don't need to serialize and deserialze whole
node again. Does it sounds more complex than we need? Any thoughts ?




To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message