Eww
For a project at work, I needed to write some application that would talk to sockets and store some state.
- Doing plain text files would be too much work (I need to parse the state afterwards, too)
- Doing a database server would be too fragile given the requirements of the system
- I don't like the SQLite API
- I don't fully know the libdb C API; but from what I remember when I last looked at it, I find it too cumbersome
- The Perl libdb API is just fine, especially if one uses
use MLDBM
, so I was planning to use that. - Doing select() in perl conflicts with using the buffered PerlIO
- I didn't like the prospect of having to use Perl's sysread
So, I was facing a dilemma here: either use the cumbersome C API to libdb, or try to figure out a way to be able to talk to many sockets all at once from perl while still being able to use buffered PerlIO.
I chickened out.
wouter@country:~$ perldoc perlembed
Fast forward half a day, and I now have an application that will use perl to talk to libdb, and that will use C to talk to a number of sockets.
I feel dirty now. But it seems to work...
I'm writing an application in C that has access to sockets and database. For the socket implementation I've used gnet (www.gnetlibrary.org). It's based on Glib so it hides much of the operating system complexity. For the database access I'm using Zild Database library (http://www.tildeslash.com/libzdb/index.html). It provides transparent access to the three most used open source database systems and has the most clean API I've seen in a library of that type.
Thanks, but no thanks
I wasn't looking for alternatives. I may have said that I felt dirty, but the code works -- and linking in perl has all sorts of extra possibilities anyway.