As we get nearer to our fine meeting, I am getting more worried about scope. Specifically, I fear we will bite off too much and accomplish little of substance.
I strongly propose that we focus on "fields in core" as a primary task. It is true that this goal splinters into many subtasks. But we should only concentrate on those subtasks which are prerequisite for achieving the goal. I think we can ignore node render and web services and PDO and lots of other shiny apples in favor of this one. It is the feature most requested by our user community, IMO.
I am spending 7 hours on trains tomorrow. I will be carefully stepping through the new CCK in my debugger and will be preparing for our "fields in core" meeting. I encourage others to similarly prepare and to focus as I've proposed.
Comments
Clarifying
I have been clarifying my thinking about (IMHO) what Drupal needs since initially proposing this meetup and absolutely agree that limiting the scope is important. My talking elsewhere in this group and g.d.o about Drupal as an application- and web-development platform is the bigger picture of "what we need," not something we can design for next week.
"Fields in core" and "data API" are very closely related. To have fields in core, we need to know how they will be represented in the core object types, loaded, saved, and manipulated; those are API issues. When designing the APIs, we should keep the larger issues of web services, object rendering, PDO, etc. at least in mind to reduce the likelihood of designing ourselves into a corner (e.g.: like where we are now :-). But "keeping in mind" and "trying to address" a topic are two very different things.
So, basically, I think we agree. And grokking the details of the new CCK ahead of time sounds like an excellent idea.
I like this suggestion
I would see this as taking CCK fields in core as our case study. That is, we are still talking about the same broader aims - consistent abstracted data APIs. We're just doing so through this particular lens. Because:
Absolutely! I was beginning
Absolutely! I was beginning to get worried we were trying to accomplish too much. Getting some sort of concrete concept of a data architecture for fields in core, while keeping in mind that it must be flexible enough for any kind of storage method, any method of input, multiple ways of rendering output, and unlimited ways of relating objects and fields to each other, including many to many relationships, seems like a great direction to go. I really do think 'everything is a field', really, in one way or another.
If we could just get to a point where we have even a general idea of what our target would look like, we could do the actual coding to make it happen as individuals and in smaller groups.
Fields in context
How to get fields in core can certainly be the main thrust, but in doing so we do need to keep in mind all of the places we want to use them: Nodes, Files, Users, Comments, etc., database-backed or SOAP-backed or calculated, etc. A plan for fields-in-core needs to be made within the larger context of "everything is a Thingie" (or whatever global plan we develop), so that we don't paint ourselves into a corner again.
Rejoice
I just wanted to second the idea of developing an abstract fields-in-core version. If fields are developed in an abstract enough pattern to apply to any-and-all desired first class objects, I think I can say the Drupal development community will rejoice. I know I will. Thanks for working on this guys because I'm definitely of the opinion that it's a needed evolutionary step for Drupal. :-)