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] OM - SAAJ like API support for OM
Date Mon, 08 Nov 2004 21:25:20 GMT
Ajith Ranabahu wrote:

>Hi,
>I am quite sure that the best way to do this would be to layer the
>SAAJ like API (can't we drop the word SAAJ here? It is confusing)
>which means that it is an extension to the existing OM !!. I mean
>"Header" is an Element so why not extend Header from Element :)
>Creating another object at the parser level (I am not quite sure what
>you meant  by saying "parser level". I am assuming that you meant "OM
>level" which means that the builder or whatever will directly output
>that structure) is kind of confusing. It effects the clarity of our
>API
>  
>
it is possible to have both options (and should configurable in OM 
builder) and ultimatley code that uses SAAJ API does nto care how SAAJ 
API is implemented.

i think OM API should be clearly separated from XML deployment options 
(such as how things are implementing OM API) so user can sepcify in 
deploymemnt optimal options of OM impl(s).

alek

>Aj
>
>
>On Mon, 8 Nov 2004 11:33:45 +0600, Eran Chinthaka
><chintaka@opensource.lk> wrote:
>  
>
>>
>>Hi all,
>>
>> 
>>
>>I was implementing the proposed SAAJ like api for OM, on the linked list
>>model. I have following questions to be clarified before I proceed on this.
>>
>> 
>>
>>If you look in to the api all the Classes coming from the SAAJ like api are
>>extending the existing OMElementImpl.
>>
>> 
>>
>>If we try to wrap OM with this API there is memory foot print problem. As
>>here we are trying to give an API for existing OM. For example if we try
>>access an OMElement as a HeaderElement, we have to make HeaderElement a
>>wrapper of OMElement. One might argue that this is not good for memory
>>footprint. But this will ease the task of OM User.
>>
>>The second option is to create HeaderElement like objects in the parser
>>level. (Earlier in the parser level we were only creating Objects of
>>OMElements, etc.), But if we try to do this, the performance of the object
>>model construction will degrade due to the String comparisons we have to do
>>…
>>
>> 
>>
>>So to expose a SAAJ like api to OM, we have two options (?? Any other
>>options ?) 
>>
>> 
>>
>>to wrap OM with the SAAJ like API. This will affect the memory footprint but
>>improve the OM user (Engine developer, Handler developer) convenience. 
>>to create HeaderElement like objects in the pull parser level. This will
>>harm a bit for the parser efficiency 
>>
>> 
>>
>> 
>>
>>Thoughts and Comments ………….. ??
>>
>> 
>>________________________________
>>
>>
>>Eran Chinthaka
>>
>>Lanka Software Foundation
>>
>> 
>>    
>>
>
>
>  
>


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


Mime
View raw message