I talked for a while to Adrian Rousseau from Bryght/Raincity and Michael Goldsmith. Adrian decided that as he's done upgrade contracts for involving CCK, he's phasing out or reducing use of CCK in their sites (where possible).

He mentioned some nice APIs for CCK2 are coming, and would work nicely with Views, but writing custom modules is faster in some cases when custom output is needed and the views support is roughly equivalent, granted all the node_example.module hooks are implemented to expose the fields to Views.

I asked if how they use CCK if at all anymore then, and they said it was good for prototyping.

At Classic Graphics, we have built a custom engine that directly queries a custom content type's tables. While using the content.module API functions should have probably be done in the first place, there are a lot of special case reasons the direct query was done and I can't imagine having to rewrite those 50-line queries every time CCK changes database structure.

This has had me thinking, instead of venturing into the world of 100% shared fields in CCK and the uncertainty of how field group nesting would get implemented and/or committed, maybe it's time to open the idea realm to consider the occasional custom content module. I spend more time re-rolling the nesting patch than I do actually making progress on it.

If we were to venture down that road, then how do we handle CCK nodereference/rolereference/usernode/date type fields? I think once the CCK handler stuff gets chopped out of those modules, you're left with just a few tiny functions that could roll into custom modules. That removes community maintenance though. It's an difficult tradeoff.

I talked it over with Chris and I think he's starting to think I'm really crazy now. Even I'm getting a feeling like it's hard to make up my mind. I think at least for upgrading our existing sites at Classic Graphics to Drupal 5, we can/should stay with CCK since I think it's still fairly straightforward from 4.7. For Drupal 6, that might be a place to consider this custom content type coded module idea instead of CCK.

I also overheard a discussion from someone trying to plug their consulting services that's related to yesterday's session about development workflow. As an example of what type of experience he offered, a possible solution to the issue of sandbox to dev to test/staging to live, he writes as much config as he can in code. Instead of configuring blocks and menus through the GUI, he writes them in code like hook_menu() and hook_block(). Then the SVN update to the live site takes care of a lot of the clicking configuration. It puts more dependencies on developers (translate in this guy's case: followup consulting), but his solution isn't totally without merit. The harder part is deciding whether or not that's an unacceptable burden to repeatedly ask developers to *create more* maintain and revise as opposed to allowing room for creating new and better. Again, I think this idea falls into the category of *a* solution, not The Solution.

My evening was spent in the Drupal Association meeting for the Permanent Members. I'm sure the important parts of the meeting will be covered in the various sessions the association will have tomorrow. I got some photos.

When I got back to the hotel, Nikki Henninger and Brenda Boggs were in the Royal Sonesta Business Center to get some Internet (it's not working in the rooms). Nikki and I had a short talk about when we worked and then stopped working at Trellon. We seem to share some of the same observations from our time there. Cheers to morbus, who was also a fun partial topic of the conversation.