After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 136466 - Deleayed SAX events
Deleayed SAX events
Status: VERIFIED FIXED
Product: libxml2
Classification: Platform
Component: general
2.6.7
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2004-03-07 17:11 UTC by Jacek Konieczny
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case (1.44 KB, application/octet-stream)
2004-03-07 17:22 UTC, Jacek Konieczny
Details

Description Jacek Konieczny 2004-03-07 17:11:46 UTC
When using push parser with SAX interface with libxml2-2.6.7 startElement
and startElemenNs functions are delayed - they are not called when start
tag of the element is read, but when another tag is read. This makes it
unusable for real-time stream parsing - e.g. XMPP/Jabber stream handling.

There was no such problem in 2.6.6 version. Upgrade from 2.6.6 to 2.6.7
breaks PyXMPP library and CJC Jabber client using that library. I wrote
simple test-case programs, which also work as expected on 2.6.6, but fail
on 2.6.7.

The problem exists in both SAX1 and SAX2 interfaces.
Comment 1 Jacek Konieczny 2004-03-07 17:22:59 UTC
Created attachment 25294 [details]
Test case
Comment 2 Daniel Veillard 2004-03-07 19:14:44 UTC
There have *never* been garanteed a that pushing data would generate
the callbacks immediately. I never made that garanteed, I stated
on request that I would not make such garanteed, the change between
2.6.6 and 2.6.7 fixes a very serious push parsing bug#134566 .
Each time someone asked about it w.r.t. Jabber support I stated
that expecting the push to flush the events out was not part of
the ABI garantee. Sorry having the parser behave correctly is more
important, I'm not sure I can "fix" the problem without significant
performance problem either. Bug left as NEW, might or might not
get fixed, but it's not really a bug, rather an abusive expectation
on the API has been changed, that's all

Daniel
Comment 3 Jacek Konieczny 2004-03-07 20:31:41 UTC
If you cannot garantee that this will not be broken permanently in
some future release, then don't fix this. I can make workaround -
parse stream input for single tags (for stream opening) or whole
elements (start tag, all children and end tag), before feeding it to
libxml2 parser for tree building. This - parsing XML before passing it
to XML parser - seems insane for me, and one reason why I choose
libxml2 for my XMPP library was the fact, that the silly workaround
was not needed in opposite to some other parsers (other reasons were:
Python bindings, speed and namespace support).
Comment 4 Daniel Veillard 2004-07-06 08:36:35 UTC
I think I fixed this in CVS, I added a Python test to make sure
this don't get broken in future releases,

Daniel
Comment 5 Daniel Veillard 2004-07-06 08:57:06 UTC
This should be closed in libxml2-2.6.11,
                                                                                
  thanks,
                                                                                
Daniel