Older blog entries for del (starting at number 2)

HTDB is 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 environments.

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 crackfucks.

big night last night

i've substantially diddled the function handler/logic black box in the guts of HTDB.

all scripts *should* be 100% backwards compatible even though this was a pretty considerable movement of code. i moved quite a number of builtin functions into the core dso function file, so the static htdblib.a is somewhat smaller.

basically, we're handling builtin functions (such as encrypt(), getval()) now in the same manner as dso functions..

before, dso functions could only be *called*, they could not be used in conditionals. now, any function you make up can be used in conditional statements just like builtins.

all function lookups go against an internal hashtable now instead of the previous array walk, so it is minorly faster as well.

also getval()/getnum() are the same thing - the way the operator is used is dependent upon the perceived *type* of the data returned and used in the conditional.

currently looking into upgrading the HTDB parsing engine to use a bastardization of expat so as to make the parsed language XML-ish, as that's what everyone expects these days... (or should i use zend?)

(later that evening...)

huzzah! it isn't everyday that you find a 40% speed increase in your software, but tonight i did just that! i was able to increase the page delivery throughput by nearly 2x using a new implementation of the file parser. now this beast's really in a position to swap-out the language engine with something better...

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!