Re: [Ann] Jivan 1.0 RC 1

Hi David,

Jivan is made very similar to xmlc to make my applications easy to mirgrate. I actually 
did propose a different page-manipulating engine to the xmlc group. There are two 
techniques, which make Jivan high performant:

- DOM repairing: Instances of the DOM are not being recreated with every request like in 
the pre-LazyDOM times. After a working copy has been used by the application, the working 
instance is compared to the master instance. Changed Nodes in the working DOM are 
replaced with copies from the master DOM. I suggsted this on the XMLC mailing list way 
back when Mark was in the middle of working on LazyDOM. Compared to LazyDOM the repairDOM 
is very easy to implement.

- original representing of the HTML: There was quite a discussion on the xmlc mailing 
list about this (see http://xmlc.enhydra.org/project/mailingLists/xmlc/msg01933.html)
Copying the string from the original HTML for unchanged node has huge speed advantage and 
the advantage, that most proprietary tags will be left unchanged (you don't need to 
educate the HTML programmer what the HTML spec says and how he should do his job)

Two things became clear in the discussion: While I wanted the validating part to be 
separated from xmlc (this means that xmlc would not try to fix invalid HTML), there 
seemed to be no consensus for this. Second, these changes would mean to reimplement huge 
  parts of xmlc if not all.


However if you look at the size of the Jivan project (lines of code) and xmlc, you will 
see that Jivan has only a fraction of the size of xmlc. So reimplementing was probably 
not as hard as it is to maintain the whole xmlc project over the time.

So I re-invented it because I saw a good chance to implemet the features I needed plus 
performance boost with probably less time than changing xmlc.

May be its time for a rewrite of xmlc anyway, people on the mailing list started to think 
about major changes (like using nekoHTML and DOM4J). But that's another story.

-Arno



David H. Young wrote:

> Arno,
> You were an early xmlc developer (and architect of the earlier xmlc 
> frameworks), so I'm curious why you decided to re-invent xmlc?  Of the 3 
> items below, the one that stands out is performance.  To save me a lot 
> of time investigating jivan, I'm curious why you just didn't propose a 
> different page-manipulating engine for xmlc?  From what I can tell of 
> the jivan from the Sample page, it looks pretty darn similar (setText 
> and all).
> 
> thanks,
> David
> 
> Arno Schatz wrote:
> 
>> Hi,
>>
>> I have been working on the Jivan Project (www.jivan.org) for a while, 
>> It is an open source project. Similar to XMLC it can parse HTML, lets 
>> you manipulate the HTML DOM and can seialize the result. It is 
>> optimized for use in web applications.
>>
>> There were 3 reasons to write Jivan and not use xmlc for HTML pages:
>>  - performance: Jivan is more than 3 times faster in table replication 
>> (see www.jivan.org   for performance result)
>>  - ease of use: Jivan doesn't compile anything and does not need to be 
>> included in the build process (hence no ant taskdef neccessary)
>>  - dealing with invalid HTML: Jivan leaves the HTML page as it is, 
>> except those places you dynamically change. Jivan parses almost any 
>> HTML without fixing (unlike xmlc). While serialisation, for all nodes 
>> (and subtrees) which are not touched by the programmer, Jivan will 
>> copy the coresponding HTML string from the supplied template directly 
>> to the output.
>>
>>
>> Jivan uses the latest form Apache.org: Xerces-2 and nekoHTML.
>>
>> Similar to xmlc, you manipulate the web-page through the standard 
>> interfaces from W3C DOM for HTML.
>>
>> check it out at www.jivan.org and give me some feedback,
>>     Arno
>>
>>
>> _______________________________________________
>> XMLC mailing list
>> [email protected]
>> http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>>
>> .
>>
> 
>