Yes, I'm a fan of callbacks, too - as long as one doesn't go too hog wild. Nothing to excess ...
As far as caching ... I really need to send you the caching db_* API :) You can cache queries as easily as caching Tcl API calls. The major problem in each case is exactly the same:
keeping the cache synched with the db.
It's the interdependencies between tables and stuff like that which makes this difficult. Caching on a query string is just as easy as caching on a Tcl API call signature and just as likely to be wrong when an underlying table changes ...
Which brings me to Jun's question. I don't favor breaking a logical join into multiple Tcl calls. That just won't scale (which you recognize by pointing out that your example didn't need to)
No ... I'm thinking about Tcl API that's high-level enough to do useful work for you. For instance to manage the insertion of content repository data in an easy-to-use way that doesn't require you to micromanage the CR. The upload file Tcl API I wrote for the CR doesn't work for types you've extended your self but is an example of useful CR Tcl API for a simple cr_revision.
The new Tcl-based service contract definitions that hide the SQL stuff from the client is a great example of what I'm talking about. Make the API writer wrestle with all the PG/Oracle differences and free the application package author from that thankless task.
ad_form's ability to manage object_ids for the caller is another (though much less ambitious) example of hiding db complexity from the client.
The CMS's ability to generate forms from content types is another example of a high-level API that should be really useful once someone figures out how to make it easy to use (and to integrate with ad_form? Oh boy!)
We need to think about high-level API that makes it easy to cobble together packages quickly.
