Re: JTidy DOM Implementation

Sami Lempinen wrote:
> Gary, do you think that SAX is less of a moving target than DOM? If
> yes, I think your proposal sounds very good. It has the following
> advantages:
> 
> - The DOM implementation would be left to the folks who know it best
>   (e.g. Xerces)
> - Maintenance of the JTidy DOM support would be easier.
> 
> The disadvantages are:
> 
> 1 Work required to design the SAX2 event generator
> 2 Speed
> 3 Existing application base.
> 
> The solution to 3) would be to either support the existing DOM classes
> in parallel or providing a smooth migration path to the DOM functionality.
> 
> Can you give a work estimate? How about the speed/memory penalty?

Sami -- 

Another disadvantage (probably goes with 2) is memory, depending on what
is used as the ContentHandler.

I'm notoriously bad at work estimates.  In this case it would be even
worse because I basically haven't looked at the JTidy code at all.  I'll
need to study the structure and then fit the code in in the proper place
so that we can maintain sync with c tidy.  I'll look at this in the next
few days and have a better idea then and report back.

On the speed/memory penalty, I have no clue.

I really want to spend my free time in the next few days studying the
JTidy structure so that I can get a good feel for the architecture. 
Measure twice, cut once.

Gary

Received on Monday, 30 October 2000 13:05:18 UTC