16 May 2001 uweo   » (Journeyer)

I wrote some code in the mean time. I also wait for the next fatal bug report for ftpcopy, but nobody seems to have found it by now. Oh well.

The new code is a caching library with some command line tools around it. Nothing complicated, just a kind of "put this into the cache and if there's not enough space then throw away the oldest entries", but it took me some days to get the bugs out. I'm quite confident that it's stable by now.

Now i want to package it up and release it to the world, hoping that somebody else will not have to reinvent the wheel. But coding for me is one thing, coding for others is completely different. I mean, it hurts to say "you are an idiot and this code doesn't work reliably" to yourself - but it hurts even more if someone else tells this truth to you.
So i better make sure ... what? That's there the problem starts.

  • Documentation. There be a manual page? Sorry, have to write this myself. But i hate writing documentation.
    This time i'm going to not use POD but tmac.an, and try to get something readable from groff -Thtml.
  • Code quality. There's a big difference between "works for me" and "works or does something reasonable in every situation". "works for me" usually means "breaks on machines with different endian or alignment requirements". Think of possible overflows everywhere. What about strange input values or a corrupted cache? I've to re-read the whole stuff. It's _so_ boring.
  • What hidden limitations do the functions have? Remove or document them (the problem is the "hidden" part).
  • Simplicity: make sure that the code is so simple that at least i don't have problems to understand it in 17 months from now. This possibly means to rewrite the function to enter something into the cache. Not funny.

  • Library API: make sure the API is consistent. I tend to not even notice "f(char *buf, bufsize)" against "g(bufsize, buf)". Make sure the functions, constants, ... have reasonable names.
  • Command line API: make sure the tools options and arguments are consistent.
  • Locking: Did i _really_ correctly document the locking requirements? I don't think i'll get it right the first time ...
That's _work_. Boring work. Stuff for some evenings.

And it's summer now. For that kind of stuff winter has been invented, i think.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!