GNOME Bugzilla – Bug 113580
Reader interface blocks on the end of node containing CDATA
Last modified: 2009-08-15 18:40:50 UTC
Reader read operation interface doesn't properly return end of CDATA/text and end of node containind CDATA/text. Such element is returned after next tag is encountered and interface is blocked until then. This make real-time (or "as it cames") XML stream processing impossible. (Bug report for version 2.5.7, which was not available on bugzilla) A python test program and patch are attached. The test program reads text from terminal and writes what it sees (in brackets). The "conversation" should look like this (text ouside braces is the input from keyboard): <a>{0,1,a}<b>{1,1,b}some text<{2,3,#text}/b>{1,15,b}<c/>{1,1,c}</a>{0,15,a} But it looks like this: <a>{0,1,a}<b>{1,1,b}some text</b><c/>{2,3,#text}{1,15,b}{1,1,c}</a>{0,15,a} As you see "some text" and "</b>" are not noticed before "<c/>" is entered.
Created attachment 16765 [details] Test script for the bug
It seems it xmlTextReaderExpand() is broken, because it seeks for the next element instead of checking if current node is finished. The previosly attached patch "fixed" Read(), so it doesn't call Expand() and doesn't block in it. But Expand() was still broken and blocking. I made new patch, probably more correct, which fixes DoExpand() to check depth of parser context, when it is the same as current node it means the node is readed completely. With this patch both Read() and Expand() work correctly. The patch is attached.
Created attachment 16774 [details] [review] Imroved "dont block" patch
Okay I applied the patch, but in general you can't rely on the instant delivery of an XML substructure from the parser, any layer inbetween may delay the delivery: network, I/O, encoding conversion, buffering in the parser, etc ... This is IMHO the major flaw of Jabber, that for working correctly one must deactivate any buffering, making it unsuitable for some processors and killing performances because this destroy locality and buffering. Daniel
*** Bug 113578 has been marked as a duplicate of this bug. ***
this should be closed by release of libxml2-2.5.8 thanks, Daniel