[Let's get started with a statement of why we're meeting and what we aim to achieve. Here's a draft. Please wade in and edit. Let's work this up till we're happy with it.]
Purpose
Drupal is well designed and at the same time needs fundamental renewal.
The core data APIs for handling basic object operations are dated and highly inconsistent with one another. There is a strong need for a basic refactoring of the core data APIs.
The current Drupal development model is oriented primarily to individual-led and single-development-cycle initiatives. While this model achieves good results when it comes to adding specific new functionality or revising individual existing APIs, it is not well suited to the necessarily collective and sustained task of rewriting APIs at a basic level.
At this point in Drupal's development we need to find new development models that match our current needs. We need to draw together teams of developers to focus on large collective tasks beyond the scope of individual initiative. Core API renewal is key to the overall success of Drupal and so of Drupal-focused firms. Hence, we need to engage the resources of Drupal firms, e.g., through dedicated staff time.
Our role in getting together at this time is not to decide anything. Rather, it is to contribute our collective expertise and energy to the community in the form of focused, informed proposals backed up with solid commitments of time and resources.
Aims
-
At a high level, map out fundamentals of a proposed fully rewritten set of core data APIs. Before limiting ourselves with details like what might be feasible when (important though these considerations may be), we take a step back and map out what a consistent, fully abstracted, schema-aware set of data APIs looks like.
-
Lay out alternatives for implementation. Having sketched out where we'd like to get, we turn to the concrete questions of what steps to take when. Can/should we dig into a rewrite in the current release cycle, or should we stage the work over two or more release cycles? How do the overall aims break logically into tasks that discrete teams could take on?
Comments
Why?
You state "there is a strong need for a basic refactoring of the core data APIs" but do not defend that assertion. Why do we care that they are inconsistent and dated? The answer is "because of where we want to take Drupal." Identifying where that is in our "purpose and aims" will help guide us in API design.
Here's my first cut for today at least:
It needs more but gets partway toward what I think is the real issue: It is too hard to use much of Drupal's core and contrib functionality in any way other than the form-driven method anticipated by the module authors. We have an application that can be hacked, not a platform for new application development.
Well put
Please edit away. We'll need to revise the Aims part as well as our approach sharpens, e.g., through taking CCK fields as a model.
Cloning nodes between sites?
Hey guys, this seems like an apt place to propose someone figure out how to push perfect copies of nodes between Drupal sites. Any takers? I know this was related to the kind of fancy business level logic that Dries was talking about somewhere. Should it be very hard using Services modules?
Good luck to all in Chi town from the MN Drupal krew.