Resource contention

I've spent the past two days migrating a very busy community site from a Windows server in Georgia to a FreeBSD server in Iowa. The new server is faster hardware, but even so the server is living on the edge of available CPU and memory. This is good, because it means I'll have to learn more about tuning a busy Drupal server.

I'm off to Washington, D.C. for a bit to work on a BEN project. I see the long shadows of CCK, actions, workflow, and views playing a big part.

OSCMS

It's now day 2 of the Open Source CMS Summit and the conference is going great guns. There's a general hum around the conference and great ideas are getting thrown around.

Strangely, the best session today for me was not Drupal-related -- it was the smalltalk session on Seaside. I'd read about smalltalk's continuations before but had never seen them demonstrated. Avi Bryant gave a demo that had jaws on the floor as he dynamically changed his (~8 lines of code) shopping cart demo while it was running. Unfortunately, Drupal is firmly anchored in the mediocre world of PHP, and that shows no signs of changing. But that doesn't mean we can't take some of the ideas, where the language allows us.

Adrian Rossouw, Earl Miles, Jeff Robbins and I had a great conversation over dinner about how actions, forms API, and web services can integrate. The theory is that actions take parameters as input, and one way to get those parameters is to fill out a form. So a browser can drive the action, but an XML-RPC call could, too. New tonight was the realization that automatically exposing subsets of actions as macros to end users who have the proper permissions solves much of the problem that we currently solve with a PHP filter, only more securely.

As I've said to several people today, what makes Drupal fun for me is a combination of working on problems and solving them in the best way possible and being surrounded by people who are smarter than I am. That stretches me, just like approaching a problem from a completely different paradigm (e.g., the smalltalk demo) stretches me.

Pre-OSCMS Summit

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.

Token-based authentication

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.

Writing

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.

Pubcookie, LDAP and Drupal

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

Vancouver

I've updated the information on the actions/workflow session at the upcoming Drupal Conference in Vancouver.

Drupal has a bright future. Recently merlinofchaos added CCK support to the views module. That means you can now create arbitrary content types and view them in predefined ways that, thanks to sortable tables and the pager, are still interactive. At the CCK design meetings in Antwerp, we had planned CCK views to be deferred until after CCK's adoption. Wow -- it's already here.

Pubcookie module

Finished the pubcookie module for Drupal today. (Hmm, project module's url aliasing for projects seems to be broken on drupal.org. I'd expect it to be at drupal.org/project/pubcookie.) I began adding support for LDAP population of new users, but decided to check it in before feature creep set in too much.

I learn something new from sepeck almost every day. Click the track tab on that page to see how prolific he is. Today I learned the proper place for module documentation.

Pubcoookie

Spent a good part of the day writing a module to enable pubcookie-based authentication in Drupal. Unfortunately pubcookie works a little differently than Drupal's built-in distributed authentication expects, as the username and password are not entered into Drupal's login form but on a separate, secure server.

user.module is a little hairy. I should clarify; I spent little time writing the module (that's easy) and more time tracing paths of execution for authentication.

Book plan

I've decided to start working on a manuscript for a book on developing with Drupal.

Drupal has seen explosive growth in the last year and a book presenting Drupal's core concepts and approaches to common problems will help a new wave of developers to get up to speed quickly.

I am aiming for coverage of Drupal 4.7. (Update: probably 5.0 too.)