I think almost all the options are on the table at this point. For the
sake of completeness I think it's worth mentioning DOM library Boost
Property Tree, which popped up frequently while searching.
I think Thibaut is right when saying that, for the way LyX is structured
now, a SAX writer would be more appropriate, because we won't work on
xml directly, but convert the LyX file. However most of the libraries
have a DOM approach, and also, if someday we'll convert LyX format to
something xml-like, we might have to start all of this again.
I did a small benchmark with pugixml and to both read and write a xml
document of 2.2Mb of equivalent ~100/120 pages chock full of math: it
takes negligble time to both read and write on my really modest laptop
A10-9600). Peak memory consumption was 14Mb, but since some MathML was
corrupted (it has trouble with backslash \) it's possible it might be
way less once fixed: LyX consumption opening the corresponding LyX file
was ~120Mb. The benchmark table in
<http://rapidxml.sourceforge.net/manual.html#namespacerapidxml_1performance>
seems to indicate that pugixml and RapidXML have performance just one
order greater than strlen, so I don't think parse time will ever be a
problem.
I'm unfamiliar with the concept of "wrapping" libraries and "layers": is
it when you write your own classes and methods on top of some common
stuff those libraries do, so if for whatever reason you have to switch
you can "plug" another easily?
Thanks, Lo.
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
