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 731626 - new stream-based XML parser
new stream-based XML parser
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gio
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2014-06-13 16:33 UTC by Allison Karlitskaya (desrt)
Modified: 2018-05-24 16:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2014-06-13 16:33:20 UTC
I started a while ago on a new stream-based XML parser.  The main API is that you ask for "next token" one at a time and get back open-tag/close-tag/text/etc.

It's based on reading from a GInputStream and has a hybrid sync/non-blocking/async API that allows one to get "next token" quickly, until it would block, before issuing an async call.

Internally it's driven by GMarkupParser turned inside out (which was surprisingly easy to do).

I've also started writing a new and more flexible GSettings schema compiler based on it.  The savings of not having to have gigantic 'start' and 'end' callbacks with a gigantic if/else/else/else mess in each is substantial.

Branch is here: https://git.gnome.org/browse/glib/log/?h=wip/new-parser
Comment 1 Lars Karlitski 2014-06-13 17:19:21 UTC
Thanks for working on this. Some first thoughts:

Do we really need set_error() and unexpected()?  Of those two,
new-compiler only uses unexpected() once in ignore_text(), which seems
unnecessary anyway to me. Why can't collect_elements() skip elements
that are not given in the list of elements (or have a NULL callback if
you want to be more explicit)? Speaking of which, I think a
skip_element() would be nice to have. I imagine that this case happens
is quite common.

GMarkupReader.non_blocking is never set.

Is there ever a reason to not pass IGNORE_PASSTHROUGH? Or did you
include that for consistency with the GMarkupParser API?

Some technicalities that you're probably aware of:
- the patches are weirdly split up
- docstrings are missing everywhere
- the binary is still called new-compiler and has a hard coded path in
  main()
- GLIB_AVAILABLE_IN must be updated
- there's a FIXME in expect_end() (check whether passthrough should be ignored)
Comment 2 Matthias Clasen 2014-06-13 23:43:43 UTC
If this is just GMarkupParser 'inside-out', I would expect some - in the patch, where you replace the GMarkupParser implementation by this...
Comment 3 Allison Karlitskaya (desrt) 2014-06-14 03:49:17 UTC
(In reply to comment #2)
> If this is just GMarkupParser 'inside-out', I would expect some - in the patch,
> where you replace the GMarkupParser implementation by this...

Other way around: I use GMarkupParser in the implementation of this.
Comment 4 GNOME Infrastructure Team 2018-05-24 16:38:35 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/888.