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.