libdebctrl
Introduction
As part of the Google Summer of Code 2009, I undertook to write a library for parsing, editing and writing control files. I thought it'd be really easy -- after all, the format is simple and consistent, right? Wrong. It turns out, there are lots of little exceptions that make working with the files tricky in various ways. Moreover, I decided to try to write it in standard C, meaning no support for objects. I tried to hack together objects using C structs, which works, but is a complicated thing to do.
Subsequently, I want to undertake to rewrite this software in a better style. I plan to write it in Vala, which will be compiled into standard C that relies on GLib and GObject for its operation. As such, I expect it to still be very fast with correspondingly good performance and portability (especially for foreign function languages, which are an important basis for this project).
Features
Core Features
- Mechanism to track API/ABI versions to ensure compatibility with bindings (and so there aren't dangerous segfaults when some things are upgraded)
- Reading the so-called "RFC-2822 alike" files. There are some strange file-specific exceptions:
- debian/control files support comments (lines starting with #), but other files only support comments through X-Comment [etc.] headers
- Object-based interface in order to work with control metadata, and also write it back to disk
- Most likely all data will be held in memory using GLib's slice allocator. I am not sure how this performs for longer-running programs, however (if there are apparent memory leaks due to the way GLib holds onto memory pages for efficiency)
- Design to allocate memory in some implementation-agnostic way (meaning, we should be able to convert between using g_slice_alloc and jemalloc or whatever on demand)
- Perhaps design a compilation scheme for low-memory/embedded systems, which would free memory more often
- This may not be feasible since GLib and GObject are pretty heavy
- Removing those is an option, but then we have the same issues as last year, and I am concerned the complexity could lead to an unmaintainable codebase
Bindings
I have experience writing bindings for Perl's XS and C, so doing this should be relatively simple. However, a solidified interface is important before doing this, as any written XS might need to be changed as the codebase changes.
I hope to be able to call upon Ryan Niebur's expertise, as he developed a rudimentary Ruby API for the library last year. Admittedly, my interface wasn't fully set by then, so this year I will need to do a better job of coordinating the implementation details with others.