I've updated the session description for the actions/workflow session that Matt Westgate and I are putting together for the upcoming OSCMS Summit. So far 44 people are signed up for the session. Wow! That's enough that we've split the session into smaller working groups after a brief intro.

When I mentioned that I was going to Vancouver, a colleague mentioned The Salmon House.

Drupal embraces other technologies. It's a bit like universal glue. There's a proposal to add token-based web service authentication to Drupal.

I've been meaning to spend more time exploring service-oriented architecture since it seems to be all the rage lately. Getting a Little Closer to SOA was helpful and the chapter from Web Services and Contemporary SOA (Part II: Advanced Messaging, Metadata, and Security) was good.

I'm still not sure enough about how to express Drupal's architecture to map it into one of the traditional box-and-line figures to think about such things, though I'm thinking about it a lot as the Book takes shape.

I'd like to see Drupal have self-defining exportable content types (that's the elusive CCK), workflow for Drupal's main types (users, nodes, comments, and documents*), relationship-based data interchange (that's publish/subscribe), actions that are triggerable by multiple inputs (workflow state changes, cron, a poke with a sharp web service call), and views. I want Drupal to internally know the difference between doing things singly, e.g., a node_load() on each of the 4 nodes we're loading, and in batches (e.g. node_batch_load()). And I think everyone who installs a Drupal site should get a pony.

*Documents are files with a node to hold the metadata, e.g. images, MS Office documents.

I've completed two chapters so far of the Drupal book, Sessions and Writing a Module. Next up, I'm tackling the form API. For that, and in preparation for Vancouver, I need to delve deep into the form code. So far it's been a nice clean place.

Checked in the new version of the pubcookie module, which now has configurable support for LDAP. I also added LDAP-to-profile mapping. When a new user logs in with pubcookie, the LDAP query can populate the user's profile if you've made profile field names match your directory server's field names. That's the Way it Should Be. Single-sign on with zero manual data entry.

All right, I'll be honest...it's not really the Way it Should Be, because Mary is going to get married and change her name, and her Drupal site profile is not going to update automatically. But at least she can edit her profile. (Chances are her LDAP entry isn't updated yet, anyway.)