GNOME Bugzilla – Bug 731626
new stream-based XML parser
Last modified: 2018-05-24 16:38:35 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
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)
If this is just GMarkupParser 'inside-out', I would expect some - in the patch, where you replace the GMarkupParser implementation by this...
(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.
-- 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.