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 Prototype Implementation Progress html file
Date Wed, 06 Oct 2004 14:17:44 GMT
here is content of HTML/Word document:
chinthaka_ajith/OmtableModelAPI/OM Prototype Implementation Progress.htm

it looks like good there are good points raised for discussion

alek

*OM Prototype Implementation Progress*

 

So far we have implemented four prototypes of OM. Now I think it's the 
time to look back and review our designs, with the experience we got 
from those implementations.

 

*Current Prototypes*

 

1.      Dasarath_Chinthaka_Ajith_Deepal implementation

 This was the initial model and this implements table model as rows of a 
table. More details about this design can be found _here_.

 

2.      Dasarath's implementation

This model introduces two major differences in to the design

1        Doubly linked lists for siblings

2        JDOM like api and removing tight DOM integration from the OM Model.

     

3.      Ajith implementation

Ajith implements the OM model with the column like table model found in 
Xalan DTM onto a JDOM like API.

 

4.      Chinthaka's Implementation

This extends Dasarath's implementation by improving children traversal 
model.

 

So now we have four OM implementations.

 

*Next ........ ?*

 

We have four implementations of OM model and they were made efficient in 
different contexts. Following things are to be noted for the future work 
of OM model.

 

1.      decoupling of DOM API from OM Model

I think one of the things we should avoid from our designs is the tight 
DOM integration we had. The major reason we did that was to support 
security on top of DOM. However one of the "mistakes" was to have /only/ 
the DOM api which is more cumbersome to work with. IMO, when we use 
security, the performance will be anyway slow. So why bother integrate 
DOM thingy in to OM itself ?

We (I think Glen also) like OM to have a JDOM like api which is easier 
to use. So this is one of the things Dasarath has done is his 
implementation.

So what is good is OM to have a programmer friendly API like JDOM and 
wrap OM, for it to support DOM API.

In this wrapping one can point to OM model, from the DOM wrapper, to 
reduce the memory footprint and to improve the performance.

2.      Since we have four implementations of OM, now we can finalize on 
OM API. One can select one of the four implementations (or implement one 
of his own), depending on the context he uses OM.

 

The proposed API for OM is available in chinthaka_ajith scratch area, as 
a suggestion.

OmApiProposal.png

 

 

 

 

 

           



Eran Chinthaka wrote:

>  
>Can some one please commit this to scratch area of chinthaka_ajith, please
>
>Thankx.
>
>Eran Chinthaka
>  
>


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


Mime
View raw message