Re: [Ann] Jivan 1.0 RC 1

Wow Arno, I am impressed.  As we say on this side of the pond, you really `put 
your money where your mouth is!

Arno Schatz <list@xxxxxxxxxxxxx> writes:
> - 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.

Yea, this is a really interesting idea.  You should have thought of it sooner
:-) It's does require some kind of life cycle management, which xmlc currently
doesn't do.  One thing that is attractive is that lazy dom is copy-on-write,
while the repair can happen asyncronously, thus improve response time.

Can you give the quick overview of the repair algorithm?
 
> - 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)

Sorry, you will never convince me that enable people to write broken html is a
good thing.  I don't believe this is what the internet is about. 

Also the current xmlc can be configured to support propritary tags; but it's
still not a good idea.

We just had to rollback a static site upgrade because the web authoring tool
that was used to create it use microsoft-specific attributes to control the
layout.  It broke in a major way on some commonly used browsers.
 
> 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.

Actually, I think using jtidy correction mechanism in xmlc was probably a
mistake.  The result is somewhat difficult to predict and since they are not
reverse engineering browser behvior, it's often not the desired results.  If I
had it to do again, it would have simple rejected invalid html.

Anyway, your benchmarks are impressive.  It would be intersting to see
some comparitive profiling if anyone has time.

Good luck..
Mark