http://xmlsoft.org/threads.html says it's only a problem if the same document is being parsed by both threads. The trouble scenario seems unlikely, offhand.
On 1/16/2010 18:40, Dan Kegel wrote:
http://xmlsoft.org/threads.html says it's only a problem if the same document is being parsed by both threads. The trouble scenario seems unlikely, offhand.
Yes, it seems so. There should be a problem sharing documents cause msxml and xmllite don't have file handles to share, and xmllite doesn't even know a filename.
What I was looking at was xmlParserMaxDepth global variable. For xmllite it should be configurable per reader instance, it's not possible now of course. I'm going to file an feature request to libxml2 guys to make it per parser context.
While we're on the subject of libxml2, there is a small problem with the way we use xmlAddChild. msxml doesn't automatically coalesce text nodes when two are next to each other in the tree and keeps them as two separate entities (you call normalize to coalesce them). libxml2 does this automatically when doing xmlAddChild.
Add a new node to @parent, at the end of the child (or property) list merging adjacent TEXT nodes (in which case @cur is freed)
Which means we can potentially have disappearing nodes. Should I also file a feature request to have the auto coalescing be toggleable? I don't think there is any good way of solving this ourselves.
I guess this would also be a vote for importing libxml2 (or at least forking it).
Mike.
On 1/17/2010 00:11, Mike Kaplinskiy wrote:
While we're on the subject of libxml2, there is a small problem with the way we use xmlAddChild. msxml doesn't automatically coalesce text nodes when two are next to each other in the tree and keeps them as two separate entities (you call normalize to coalesce them). libxml2 does this automatically when doing xmlAddChild.
You're right. I spotted this some days ago while catching leaks reported by valgrind. To block this feature which itself is good a deprecated IXMLElement API screws up node type directly. This is a real problem speaking about leaks - libxml2 won't free node properly after such intervention.
Related code is in xmldoc.c: --- node = xmlNewNode(NULL, empty); node->type = type_msxml_to_libxml(V_I4(&vType)); ---
Proper way is to use xmlNewText, etc. Like we do it in DOM interfaces.
Add a new node to @parent, at the end of the child (or property) list merging adjacent TEXT nodes (in which case @cur is freed)
Which means we can potentially have disappearing nodes. Should I also file a feature request to have the auto coalescing be toggleable? I don't think there is any good way of solving this ourselves.
Actually I posted a request in existing bug report here: https://bugzilla.gnome.org/show_bug.cgi?id=427622
It's about what I'm started with - allowed parser depth. Honestly I don't expect this change be accepted in libxml2 cause programs dependent on exported global variable won't work as expected.
I guess this would also be a vote for importing libxml2 (or at least forking it).
Mike.
Fork isn't needed actually, a bug fixing manual merge from time to time with off. repo will be enough.
Let's see Alexandre's opinion on this.
On 1/17/2010 00:11, Mike Kaplinskiy wrote:
While we're on the subject of libxml2, there is a small problem with the way we use xmlAddChild. msxml doesn't automatically coalesce text nodes when two are next to each other in the tree and keeps them as two separate entities (you call normalize to coalesce them). libxml2 does this automatically when doing xmlAddChild.
Add a new node to @parent, at the end of the child (or property) list merging adjacent TEXT nodes (in which case @cur is freed)
Which means we can potentially have disappearing nodes. Should I also file a feature request to have the auto coalescing be toggleable? I don't think there is any good way of solving this ourselves.
After some digging I think we could use xmlNewTextChild to create text nodes. This will prevent coalescence and leave a new added node as is. New type will be XML_ELEMENT_NODE though, so it's a partial solution cause type not preserved.
Hi*Nikolay*,
If I'm right then only solution is to link to libxml2 statically from each module. Is it an acceptable way?
P.S. having a separate copy of libxml2 allows to tweak its namespace support (I believe there's some discussions of that problem in bugzilla).
I think it would be better to avoid using libxml2 for xmllite implementation. Writing XML parser from scratch is easy and we can avoid problems with incompatibilities.
Jacek
On 1/19/2010 19:36, Jacek Caban wrote:
Hi*Nikolay*,
If I'm right then only solution is to link to libxml2 statically from each module. Is it an acceptable way?
P.S. having a separate copy of libxml2 allows to tweak its namespace support (I believe there's some discussions of that problem in bugzilla).
I think it would be better to avoid using libxml2 for xmllite implementation. Writing XML parser from scratch is easy and we can avoid problems with incompatibilities.
Hi.
Actually I don't see (yet) any incompatibilities for xmllite, except depth security threshold. I'm not very familiar with parsers in general, could you help me please with some useful links or good examples of already implemented simple xml parsers (except libxml2 of course) that you could suggest as good start.
Jacek
On 1/19/10 9:26 PM, Nikolay Sivov wrote:
On 1/19/2010 19:36, Jacek Caban wrote:
Hi*Nikolay*,
If I'm right then only solution is to link to libxml2 statically from each module. Is it an acceptable way?
P.S. having a separate copy of libxml2 allows to tweak its namespace support (I believe there's some discussions of that problem in bugzilla).
I think it would be better to avoid using libxml2 for xmllite implementation. Writing XML parser from scratch is easy and we can avoid problems with incompatibilities.
Hi.
Actually I don't see (yet) any incompatibilities for xmllite, except depth security threshold. I'm not very familiar with parsers in general, could you help me please with some useful links or good examples of already implemented simple xml parsers (except libxml2 of course) that you could suggest as good start.
We have a very lite, but also very customized, XML parser in dlls/ntdll/actctx.c. It mixes parsing with interpreting, but it should give you a good view on how to write such parser.
Jacek
-
Dan Kegel -
Jacek Caban -
Mike Kaplinskiy -
Nikolay Sivov