Spam: The other white meat

One of the funny things about getting Drupal coders together in a room is that in my experience, more often than not, you get a whole lot less code than you would expect. What you do seem to get however are high level converstations about architecture, implementation, and user experience.

Over the big tables at Mansueto, we discussed different ways of approaching the problems of file handling in Drupal. One area that we really ran up against in Drupal 7 core are the implementations of File and Image fields. From our conversations we see the specific image field as a mistake (well this is my conclusion anyway). The intent of the Media Module) is to decouple file storage from file display formatting- from this perspective perspective Image field mistakes this mistake by reimplementing file field with some formatters. Media seeks to serve as a file selection system which utilizes something like File field as its data store. The file selection process can use local, external, as well as "non" file data (eg: YouTube embeds).

Peter Wolanin (pwolanin) worked hard all weekend to build a new implementation of the File field widget that would allow us to overlay the media module functionality on top of the core functionality also allowing us to effectively replace the Image field widget.

In the process of talking this all through we are coming to some agreements about what "counts" as file metadata and what does not. We put together a quick module (file metadata) that can act as a simple meta data store. We will likely extend this in the future to implement EXIF and/or GetID3 to capture existing file metadata along with an interface to edit (and save to file) metadata.

We also made good progress in pulling together some of the interface elements that we need to build the file browser interface. The default elements are almost completely in place for other modules utilize the default interface.

All and all, highly successful and lots of fun ta boot.