On Saturday 27. February 2010 07.16.40 Ganesh Paramasivam wrote:
> As you can see, these rules actually imply a modification of the DOM. We
>  already have a working code for loading delete changes which does not
>  require a write-able DOM tree. But the code would be a lot more cleaner
>  with a write-able one. Hence this change.

Hmm, this is a double-edged sword. While the changetracking may get cleaner 
I'm no fan of breaking abstraction levels.
The assumption that while loading the DOM stays unchanged is a really useful 
one to avoid a lot of debugging. It is also a useful one to allow memory 
consumption optimizations and speed optimizations.

In other words; while I trust you are right that the changetracking loading 
gets more complicated, your change breaks the assumptions of loading and that 
has the long term potential to make a lot more problems.

I'd like to know what others think, is this a tradeoff that is worth it? Does 
this concept change make things (ODF) loading harder to maintain?

I'd personally thing its best to go for the change-tracking loading doing a 
second pass and thereby limiting the impact of this complexity to one nice-to-
unit-test place in the code.
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel