axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [Axis2] Some more notes
Date Tue, 15 Mar 2005 04:36:15 GMT
Eran Chinthaka wrote:

>Good Effort Venkat. See my comments below.
>
>  
>
>>Not any burning issues; i'm just thinking aloud while going through the
>>code.
>>
>>- methods in OMElement and OMNode seem a bit mixed up. The
>>getter/setter methods for parent and siblings are available in OMNode
>>and they use OMElement and OMNode respectively. The getter/setter
>>methods for children are available on OMElement and they use OMNode.
>>    
>>
>
>The reason for this comes from the architecture of OM itself. Parent can
>only be an OMElement. OMElement can have OMNodes as children, which happens
>to be OMElement and OMText. We have to *fully* preserve the infoset. So we
>must maintain the text and elements order as well. So in the linked list
>implementation of OM we maintain these as a linked list of OMNodes. So
>getter/setter methods for children are always using OMNode. 
>
>  
>
>>Actually the confusion exists in SAAJ itself, where
>>javax.xml.soap.Node has setParent and getParent using SOAPElement. May
>>be i didn't understand the role of these two interfaces. However
>>org.w3c.dom seem to have clear roles for Node and Element.
>>
>>- setParent* methods SAAJ and adppendChild in DOM detach node from the
>>currrent parent first. OM implementations for these methods do not
>>detach node, and might end up in having multiple parents. 
>>    
>>
>
>Thankx. It was a mistake. I fixed that. 
>
>Also
>  
>
>>setParent looks redundant when we have appendChild methods doing the
>>same (applies to SAAJ also).
>>    
>>
>
>Well you have the two ways to do the same thing. ;)
>
>  
>
>>- Almost all Impl classes "implement" OMConstants, may be to optimize
>>the access to the constants, but might reduce the clarity of code.
>>    
>>
>
>Well I thought this is a normal practice. For example, rather than saying,
>OMConstants.XXXXX, XXXX is more straight forward. This came from my
>experience. One would say, this is some sort of misuse of interfaces. But
>.....
>
>  
>
>>I think we are taking a bold step by defining OM as our own Axis
>>specific alternative to DOM and SAAJ to give us performance, which is
>>very refreshing and exciting too. 
>>    
>>
>
>Yeah, sure. I think we must be proud of our OM (at least I do). We are the
>first to implement an object model with differed building still with very
>good performance. We have proved that. 
>  
>
XPP2 had this capability few years before OM and i am happy to see that 
AXIS2 will now have it.

>The best way to predict the future is to invent it. (Thankx Alek ;))
>  
>
yes - it is the most interesting part of during software for me: one of 
domains where one can explore new horizons and see current "cutting 
edge" becoming "outdated" in few years  ...

alek

-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message