Re: Xmlc: [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
> > XMLC@xxxxxxxxxxx
> > http://www.enhydra.org/mailman/listinfo.cgi/xmlc
> >
> > .