improving by fits...
since most of my time is actually spent *using* the tool, i
haven't had much time recently to *improve* upon it - which
i guess is a good thing. it means that i must be doing
something right that i don't have to diddle with the core
library too much.
but diddling i have been... in the past few days,
HTDB has been extended to: have a nicely mask-driven
embedded debugging/logging mechanism incorporated as a DSO.
then built on top of that is the handling of DSO error
conditions as loggable events.
elsewhere, i've realized another way to use the tool! once
i had the "ah-hah" that i could actually be making database
calls from within arbitrary DSOs, i realized that i could
build web pages from the "inside-out" instead of the
"everything inna bucket" approach i've used for so long.
in otherwords, HTDB *can* be used in a more procedural
manner that everyone expects from HTML/scripting
it also means that i'm able to centralize programmatic logic
guts away from UI components in callable DSO C functions.
3-tier systems..? bring it on.
in the last week, i was able to add to garageband.com a
database-driven, completely extensible promotional giveaway
sub system using the HTDB framework. i was afraid i was
going to have to suck "when to show what" logic right into C
code, but i ended up just having to code some meta logic and
database glue in about 40 lines of C and the rest is
completely HTDBscripted and modularized. very pixel-pusher
friendly - which is the whole point of HTDB.
but of course... no one but me has any idea what i'm ranting
about, so i'll stop.
(but this stuff is too cool! and it keeps suprising
me with its different uses just waiting to be discovered.
what is HTDB? HTDB is math - just there and perfect :-)
oh yeah. htdb.org is down right now. lamo loser