2011-10-03

Code libraries

When writing something new there is invariably a key step in the process of do I use a standard library or not?

Now there are a lot of very good long established functions in glibc, and unix/linux generally which I use a lot, obviously. No, what I am talking of here or more esoteric things like processing iCal entries (RFC5545). iCal is just the latest in a long series of examples that almost always come out the same way and mean I end up writing a new library.

One of the problems is that some of the libraries are really bloated when all you want to do is something simple. I had this when I wanted to create a gif or png and the libraries were a nightmare. I ended up making a very simple image generation library which is a doddle to use and very small and fast. The ical library is like that, /usr/include/libical has 45 files totally over 10,000 lines, just for the include files! It took me all morning to find the functions I wanted. Sadly ical time stuff is in fact a pain in the arse to code, so I was really hoping I could use the library. The good thing about a big library like that is that they usually have done a good job.

The problem is that some libraries, especially big ones, can often do nearly what you want. And to use them properly you have to do something extra, or worse, fix the library. Fixing the library gives most of the same problems as having your own library, unless you can convince the author to take on the fix. But the biggest headache is reading and fixing other people's code is never nice - I am sure I am not alone in that!

Well, libical is no different. I thought I could use it, but just trying to use it this morning I have hit some show stoppers. For a start, one of the biggest annoyances, is inconsistency. It seems the parse function does not understand folded line, so I have to unfold the lines first then feed in to the parse - a minor annoyance, but the output function does understand and generate folded lines - why the inconsistency? The next problem is that the parse understands character escaping like \n but the output does not, and so you get syntactically invalid output, and guess what? outlook generate fields with \n in them. So, basically, I have no way to output the ical data in a format that could be parsed by anything. There is more, but that was just enough to convince me I am on to a loser using the library.

What can I say, arrrrrrrg!

1 comment:

  1. I hate it when people *don't* use existing libraries. Sure, the existing library may need to be tweaked to work exactly as required, but when people reinvent the wheel over and over again it just leads to the same (and different) bugs being implemented over and over again.

    Have you filed a bug upstream (at sf.net for libical) or in a distribution (e.g. Fedora) bugzilla? Can you provide a simple test case showing the misbehaviour/inconsistency?

    ReplyDelete

Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

Missing unix/linux/posix file open option

What I would like is a file open option for "create replacement file". The idea is that this makes a new inode in the same mount p...