One of the more interesting DrupalCon DC sessions from my perspective was one describing the in-progress core Fields module. It is heavily based on CCK and will replace CCK in Drupal 7. The development is ongoing and has benefited from a number of recent code sprints.

I'm excited about this module for a number of reasons. First and foremost, it will allow fields to be added to any object- not just nodes. This includes Users, Nodes, Comments, data pulled from outside sources - whatever. Needless to say this is going to be very useful, potentially replacing modules like Profile with core functionality.

This is done through some carefully thought-out APIs that will once again change how custom field types are created, though hopefully for the better. According to the presentation (found below) it's a return to the data level/GUI level pattern found in D5 but departed from in D6. Probably the very best part, however, is that the API documentation will be included in core and will thus be accessible.

It also occurs to me that this prepares Drupal in some small way for the semantic web - part of so-called Web 3.0 - with the ability to annotate incoming data with useful data fields. Speculative at this point to be sure, but that's how I imagine it.

Finally, something not expanded on greatly in the presentation, the field CRUD (Create, Read, Update, Delete) API. It allows for fields to be added programmatically, something only possible previously through awkward macros. This is awesome for a number of reasons, not the least of which is that modules can now leverage previously written field types, reducing development time and increasing configurability to the end user. That's cool. I envision some sort of Views-like 'suggested' content types that are configurable yet retain all the aspects that allow the contrib module to do its work.

An example of this might be a mapping module that uses a geographical data field; up to now the contrib module would have to supply the GUI for inputting geographical information on a node, along with all the database interactions to store the data. It might give us input widget options, if the developer is inclined. If things work the way I imagine, the developer of the module would simply require a particular field type to be present in an object, any object - in this case one that stores geographical data - and would relinquish responsibility for inputting and storing that data. This means we could plug in any input widget we wanted, and boom, the module is far more useful. I can't tell you the number of times a contrib module has provided the exact features I've needed, but the interface isn't appropriate for the situation.

Please keep in mind that this is my vision and I have no idea at this point whether this might happen. I'm definitely going to following this story for D7.