ABI stability for GXml

I’m taking a deep travel across Vala code; trying to figure out how things work. With my resent work on abstract methods for compact classes, may I have an idea on how to provide ABI stability to GXml.

GXml have lot of interfaces for DOM4, implemented in classes, like Gom* series. But they are a lot, so go for each and add annotations, like Gee did, to improve ABI, is a hard work.

I think is better to improve Vala code to produce ABI stability from the beginning; this will help GXml, GSVG (implementing W3C SVG 1.1 interfaces) and GSVGtk, to have abstract classes and interfaces with good ABI stability without change a line of code in them.

In the process, we can have reproducible API, that is: same C header from compilation to compilation of Vala code and when you add new API. Of course, this means that you should follow basic rules when write Vala code, but no more than the ones on the C side, well may be a few ones. When this is in place, you may add your library header to your repository to track changes to it; once a new API has been added, you should be able to take care about ABI and API, to make sure they are consistent over time.

 

Productive language for GObject, GType and non-GType based software.

Author: despinosa

Linux and GNOME user, full time, since 2001. Actual maintainer of GXml and contributor to other projects mainly on GObject Introspection support.

2 thoughts on “ABI stability for GXml”

    1. My involment in GXml was large XML precisely. I have to manage files up to 60MB, no zipped. So performance and resources are important for me.

      GXml started using libxml2 and have been wrapped through GXml.G* prefixed classes, like GNnode.

      Then I added a new GXml.T* classes series, using GObject to re-parsing libmxl2 tree. Much more memory, better memory management, but increased performance in GObject to XML serialization process.

      Now on a new GXml.Gom* classes series comes in the scene, it improves performance on reading and writing XML files, while is very close in memory demands, against the one based on libxml2 tree G* series.

      https://blogs.gnome.org/despinosa/2016/12/12/gomdocument-providing-best-of-two-worlds/

      I’m figuring out how to increase performance on reading, buy using multithreading parsing, but that means a way to split out XML file in buffers containing XML nodes, so its parsing can be done in a different thread.

Leave a Reply to despinosa Cancel reply

Your email address will not be published. Required fields are marked *