The Future of Fields

or,

How Snow and Flu in Chicago Clarified What Drupal is Good For

Data Architecture Design Sprint

• I will embed our group photo on the porch in the snow here (I don’t have the memory card handy at the moment).

Goals of the DADS(or so we thought)

• Re-design Drupal's core data architecture– Data API– Object modeling– Fields in core– Many related ideas

• Propose a design at Drupalcon– Voilà!

Our Grand Conclusions

Drupal’s raison d'être

Drupal’s architecture allows

contributed modules to easily

add value to content.

The Future

• Web services– Consuming– Providing– Enhancing

• A monolithic web site is like an off-network computer – i.e. It’s useless.

The Path Forward

• Apply Drupal’s value-add contrib modules to web services

• Consume– Treat local and remote data as equals– Allow contrib’s value to apply to either

• Provide– A topic for another day

Data API needs

• Consistent set of methods for all entity types (user, node, etc.)

• Defined set of fields with known structure and predictable representation

CCK Fields as model

• Already exemplifies much of what we are aiming for– schema aware– predictable representation—in db, in object

• Strong demand for fields in core—should be not an add-on option but a new model and step forward

• Ironically, admins have a richer set of tools than developers do

Fields in Core•Preliminary work in D6–Separate directories–Split out API from UI–API in new Fields module, developed in contrib with aim of core–UI remains in contrib

Fields in core: Minimal

•Code-level methods for what is now UI-based•UI remains in contrib•Still limited to nodes•A small number of sample fields converted

Fields on Remote DataDrupal is a client of a remote serviceRemote service exposes entities and their fieldsExample implementation for D5/D6:generic module set plus supporter service

Clients module set

Specific client per external service

Field configuration

How You Can Help