blog.s11n.net

New Project: cpdo database abstraction API for C

Hello, C hackers!

Inspired by a recent project at work, where i had to write a DB abstraction layer for wrapping MySQL and Oracle, i’ve started a new database abstraction library for C:

http://fossil.wanderinghorse.net/repos/cpdo/

cpdo gets its name from the PHP PDO API, after which it is modeled.

It comes with a driver for sqlite3. Work started on a MySQL driver, but their prepared statements API is essentially unusable from such an abstraction layer (as best as i can determine, anyway), so i gave up. (Update: and later got it working - see below.)

The original wrapper (part of a commercially-supported add-on for the Nagios monitoring framework) only needed “plain SQL” support, not prepared statements, and thus worked fine with MySQL and Oracle. (We replaced their usage of libdbi so that they can support Oracle.) With cpdo, i decided to “implement it properly” and internally use only prepared statements for all SQL. This, however, this appears to be essentially impossible using the MySQL API, so we’re left with an abstraction layer which abstracts only sqlite3 for the time being.

If there are any MySQL-loving C gurus out there with too much energy on their hands who would like to help implement the MySQL binding (or for some other database), please get in touch. i’ve implemented the driver skeleton and maybe 1/3rd of the code (e.g. connection, disconnection, and the first step of preparing statements), but can’t proceed because the MySQL prepared statements API is so insane. Update 2011-Jan-31 @ 00:17: The MySQL driver is now basically working. There’s more testing to be done, in particular with BLOBs and large string fields, but it appears to work. Thankfully, i found a useful example (most aren’t!) of how to use the MySQL in the PHP source tree (for their mysqli bindings), and that made all the difference.

Happy Hacking!

—– stephan beal

New Project: v8::convert

Hello, fellow v8 hackers,

(If you have no idea what a “v8 hacker” is then this post will mean nothing to you.)

i would like to announce a new v8-based project…

v8::convert is a header-only utility library for Google v8 with a very small focus:

• Converting between v8 and native values, including client-defined types.
• Converting C/C++ functions/methods to v8::InvocationCallback implementations.

With those two features we have almost everything we need for most class-binding purposes. The the ability to convert functions to have v8::InvocationCallback signatures has proven especially useful, and allows us to plug in in many C-standard or 3rd-party APIs with ease. Conversions are compile-time typesafe where possible and runtime conversion failures fail gracefully (e.g. by throwing a JS-side exception).

The core components are in no way project-specific, and can be used in conjunction with arbitrary other function/class binding mechanisms. Since the implementation is header-only, it’s particularly easy to include into other projects.

The API is trivial to use. The client API contains a good number of classes and functions, but most client code needs only one or m/ore of the 5 main function templates: CastToJS(), CastFromJS(), FunctionToInvocationCallback(), MethodToInvocationCallback(), and ConstMethodToInvocationCallback().

The missing parts are:

- Binding JS accessors to native values/functions. i have the code in v8-juice but need to port it to this API’s conventions.
- A class binding mechanism which takes care of the WeakPointer bits. There is such a mechanism in v8::convert, but it is not considered a core component because hackers tend to each have their own favourite class binding mechanism.

The code is largely a spin-off of the core-most v8-juice components, but the function-binding parts were re-implemented from scratch so that we can use function-pointer-style template parameters (which, IMO, are more readable than the v8-juice’s approach). Additionally, instead of inheriting v8-juice’s huge collection of weirdly-named function-binding templates, clients now need only 3 templates to bind functions (one each for free functions, const- and non-const member functions).

The idea of doing a header-only spin-off has been brewing for some time, but i was recently inspired to finally do the work by two other v8-users list members:

- James Pike: when i saw how vu8 takes advantage of function-pointer-style template parameters, i just had to have that feature for myself.

- Fuzzy Spoon: the separation of const- and non-const member handling was prompted by Fuzzy’s report about MSVC not being able to select the proper template specializations when the the member functions differ only in constness.

v8::convert is only about 3 nights old, but already has at least as much API documentation as v8 itself. There is an overview and example code here:

http://code.google.com/p/v8-juice/wiki/V8Convert

The source code is at:

http://code.google.com/p/v8-juice/source/browse/#svn/convert

It includes a standalone demo application and a demo v8-juice plugin.

Happy Hacking!
—– stephan beal

New project: cson JSON API for C

Hello, fellow C hackers! (Everyone else can stop reading now.)

i couldn’t resist the urge: i had to try my hand at writing a JSON library for C:

http://fossil.wanderinghorse.net/repos/cson/

cson (pronounced “season”) is my first JSON API for C. Its design is based largely on that of its “genetic stepbrother”, libnosjob (C++ JSON library).

It’s brand new and “might” still have a few bugs. It uses more memory than it really should when reading JSON, but i hope to eventually rectify that. Its main claim is that it can read JSON from damned near anywhere and write it to damned near anywhere. I/O implementations are provided from reading/write JSON from/to C-standard FILE handles and strings, and adding support for new i/o types (e.g. C++ strings or other custom stream types) is really easy.

If you’re (still) looking for a reasonably nice C API for consuming and generating JSON data, cson might be interesting for you.

Happy Hacking!

—– stephan beal