Re: [Ann] Jivan 1.0 RC 1

Hi Mark,

Mark Diekhans wrote:
> 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?

Sure:
First the master DOM (MD) is created from the template.
then the working DOM (WD) is cloned from that, with two mappings
node of MD --> node of WD and vice versa

now users program will chage the WD. THe DOM implementation is keeping track of 
'node-changed' and 'subtree-changed'. 'subtree-changed' means that at least one subnode 
of the current node has changed.

After the users program finished using WD, the repair workslike this:
compare structure of MD and WD, check for each node in MD:
is the current node in WD the same as current node in MD mapped to WD (using above 
mapping MD->WD).

if no, remove current node from WD, insert the current MD node mapped to WD.

check if the (new) current node in WD has 'node-changed' set, if so compare attribute / 
copy attributes from MD to current WD, same with node value. (Note: node name can't change)

if 'subtree-changed' is set, recurse this algorithm into subtr.

end.

This is basically it. I left away some corner cases, but not really anything 
major.
The main part of the algorithm is really less than 100 lines od code. If anyone 
interested I can point to it.

>
>
>>- 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.
>

I know. My point is, that the whole industry (browsers and other UAs) do enable people to 
get away with broken html. So it is practice in the industry to write broken html. And a 
tool vendor wit insignificant market share should deliver tools to support these common 
practices. We can't change the them. And I am actually tiered and sick of explaning UA 
designers what standard conformance means. Nobody cares.
But hey, I am not trying to convince anyone, just my opinion.


> 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.

also jtidy produces so much warnings and other output which is not relevant (e.g. if 
table tag has no summary attribute it throws a warning). Most developers don't even look 
at the xmlc produced logs/errors. They just look if it comes out in the browser ok, 
that's it.

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

would be interested in it too. It seems both do spend most of the time in the 
serialisation process...

>
> Good luck..
> Mark

thanks,
  Arno

> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc
>