Gah~ I don't usually post so much, but I was looking into this really quick before getting back into my Sims 2 game and I just tested it out.

The current Tagadelic HEAD (revision 1.38, Sep 15, 2007) has a caching scheme that seems to work with my site. It makes use of Drupal's already established cache API, which is even better than anything I would've thought of (I'm not very familiar with drupal's internals). The code can be found through this old Tagadelic feature request -- here's the final patch.

However, it's not yet been committed to the current stable releases. I basically had to roll back any of the other changes made to the stable branch after Sep 15. I suppose I could do the job of porting it myself, but... wait, that means I have to work! Also, I'm shy, and unfamiliar with CVS. ;.;

[edit]

I've done some more tweaking with the caching patch, after looking into this book page on Drupal's cache API, a great Drupal 5 tutorial titled A Beginner's Guide to Caching Data and the Drupal 5 cache API documentation.

I wanted the tagcloud to update whenever tags or nodes are added/deleted, so I had to alter the tagadelic caching code so it would cache into the cache_page database instead of the default cache. This is because the node and taxonomy modules already automatically call cache_clear_all() when nodes, terms or vocabularies are altered, and cache_clear_all() flushes the cache_page cache when called. (In Drupal 6, it also flushes the cache_block cache.)

After making that initial change (from 'cache' to 'cache_page') I did some testing and found out that the tagadelic cache still wasn't getting flushed. Ack! So I went into the database to see why, and saw that the tagadelic cache was being marked as CACHE_PERMANENT. This was because the call to cache_set() in the tagadelic module was using the default value for $expire, which happens to be CACHE_PERMANENT. So I changed the cache_set() call to explicitly set $expire to CACHE_TEMPORARY, meaning the tagadelic cache will be flushed as expected when a general cache wipe (i.e. by cache_clear_all()) is made.

If I'm still using this hack by Drupal 6, though, I'll have to remember some changes to the cache API:

1) Calling cache_set() or cache_get() won't require complex data to be serialized or unserialized first. Such data will be recognized and un/serialization done automatically by the cache API.

2) The order of the args for cache_set are changed. Currently they are:

cache_set($cid, $table = 'cache', $data, $expire = CACHE_PERMANENT, $headers = NULL)

In Drupal 6, they are:

cache_set($cid, $data, $table = 'cache', $expire = CACHE_PERMANENT, $headers = NULL)

So basically the order of $table and $data are reversed. :O Presumably to allow $table to be an optional arg. Not a big deal, but it's something I'll have to remember when porting themes and modules (and possible accompanying hacks) over to Drupal 6.

[/edit]

But for now this caching solution seems to work. I've saved the patch, I could potentially add it manually to my module, and I've posted this entry to remind myself of it.

P.S. Note that the "more" link on the tagcloud is gone now, 'cause it was a feature in the stable dev branch. I'll either have to patch the caching code into the current stable version myself (and thus each time I update tagadelic), or get over my shyness and have it included with my small changes in the new version. :P