GDA project has released 5.2.5 and tagged 5.2.6, with some improvements, but the real work is on master.
Master is targeting 6.0, a new ABI/API release, providing better GObject Introspection support and code modernization.
A new Meson build system is on the way to replace Autotools. Meson helped to implement, fix and test all changes in less time. Like on multi-threading, where is more easy to produce multiple parallel tests, helping to expose issues to fix. Master have big improvement on that matter.
API is almost the same with minor changes, so port to new one should be easy. Major API breaks will happen on 7.0 development cycle.
GDA have really old code, modernization of public API has been the priority; but, some parts are very sensitive to the change, so they may never will change or will wait to 7.0 cycle.
GDA’s GTK+ widgets, has been ported to avoid Deprecated API by recent 3.x releases. No heavy changes here, apart of the code modernization. GDA’s Control Center and Browser, has been fixed, so they are back from the dead. There are other, more modern applications out there like Sequeler, so in the short term may this tools old will be removed, unless there are interest by users.
My experiment on mix Vala code with C source in GDA should wait, but I found it functional, just some improvements in Vala code generation adding C source documentation are required.
Beyond 6.0, there are interest in improve implementation of new database Providers. At first, I’ve tried to make more deep changes in API to make room for a new providers platform, but the way current one and connection objects are tied each other makes that hard, so I decided to wait until 7.0 cycle starts.
In parallel, I’m developing a new Vala library called libvda, to experiment with a new platform for providers. It is exposing a set of interfaces, making more easy to have new providers; load them thought libpeas is planned.
Currently libvda has objects to connect to PostgreSQL and SQLite, using a common GDA provider object; add more existing GDA’s providers is a matter of a really few lines of code, thanks to Vala.
Because GDA has a very slow mechanism to generate Meta information about data base’s objects, I plan to expose meta queries directly, so they can be used faster. libvda, expose interfaces to access meta information using a GObject API, but there is a new DDL module in GDA for meta information, but that is another history for a different article.
Design and implement interfaces an objects in Vala is about 8 to 10 times faster, considering API changes in the development process. This is why I can expend time on libvda, to check out how could be on GDA and why I’m considering to mix Vala source code with C one.
What do you think of projects like vlang – https://github.com/termNinja/vlang , might be worth pursuing, I hear its much easier to build compilers for object orientated languages like vala using llvm now that its picked up the statepoint functionality.
Maybe look at a language level vala package manager too 😛
Vala now produces C code and LLVM can be used as compiler using –cc=COMMAND switch on valac. Vala uses a Object Oriented approach to construct a AST and also one to produce C code output.
I would like to add a set of interfaces to Vala, so we can get different parsers and output code generators. So you can write code in Vala and get a C or Rust code output, using any compiler. On parser, is possible to add custom token parsers, to extend the Vala language to new keywords, like embedded SQL commands.
Out of curiosity, how hard is it to maintain ABI compatibility ? One of the remarks I heard a few times about Vala is that it has had issues with ABI stability in the past, even from yourself [1].
[1]: https://gitlab.gnome.org/GNOME/vala/issues/598
Vala’s compiler now has a –abi-stability switch, so all the code you write in Vala is reproduced in C in the same order to warranty ABI stability. So, write an Interface, struct or Virtual methods in class should be keep in the same order in your Vala code along your ABI stability, as is in C.
Remaining issues are related on adding classifications of public and private members, that where exposed in the public API, but I think is less important, because once you are using ABI stability, the order matter so classifications in output C code may not reflect the real use of the member.
So ABI stability is here, but used just for libraries.