We talked a lot about minimum viable functionality (MVF) for D7 core. We also talked briefly about what criteria to use to decide what should be in core vs. contrib. I'd like to revisit that.
Question: Why bother putting fields in core at all?
Being in core has many drawbacks. Much slower development/release cycles, necessity to gain broad consensus for everything, requirement to operate in every possible environment that Drupal supports (e.g. low-memory hosting), etc. We already have CCK and fields in contrib. They work great. Why are we going to incur all this extra pain?
I think the answer to "what should be in core" is "those things that provide substantial benefit and simply could not be done outside of core because they require fundamental architectural support or the like."
CCK fields on nodes do not meet this requirement. We already have a 'body' field. Just providing a new way to have a 'body' field is not interesting or useful enough to incur the extra effort.
Instead, I assert that the MVF for fields in core needs to include something that is just not possible with CCK in contrib. Among the things we discussed in our sprint, the ability to add fields to remote content is that thing. Fields on remote content will by itself make D7 a killer release, leaping Drupal past its competition. I think it will make Jeff, Acquia's VP of marketing, drool. I think this is the goal we need to strive for.
I have a basic grasp of how to implement my proposed Content Model 1 and I do not think it will be a monster task; most node code and functionality will remain the same. I still want to see Larry's writeup of Content Model 2. Then I/we should get to serious work on nailing down the Content interface (or Fieldable as I've suggested renaming it) or whatever Model 2 uses.
Thoughts?
Comments
yet a different justification
i agree that i can't get all that excited about doing exactly what we do now, but in core. but i do get excited by the prospect of attaching fields to users or user profiles, and really moving beyond the profile.module once and for all. so, if we need alternate justification, there you go. we'd really clean up the node profile/bio chaos.
Well, that's a turn :-) I
Well, that's a turn :-)
I guess we'd need to recollect why there's a long-standing demand for 'CCK in core' in the first place. The ones I can come with are :
- establish that CCK fields are an integral part of Drupal's features, and taken in charge by the community as a whole, independantly of the availability of it's current two maintainers. Related : ensure CCK upgrades do not come 3 months after Drupal releases, making it more difficult for drupal releases to 'take'. That's 'CCK (and usually Views) are the part of core that are not in core'.
- ensure this critical feature is backed by solid, clean ('core-level') code. CCK contrib currently works, but the code could definitely be cleaned and overhauled. Agreed that being in core is not a strict requirement for that, but that point is directly related to the number of community eyes on the code.
- CCK upgrades are a huge pain, and this is to a large extent directly related to CCK being a contrib module just like any other one.
- As Moshe pointed, we want to get rid of profile.module (although our 'sprint' did not really make it clear whether users would be 'Fieldable' themselves...)
- CCK (ok, and imagefield...) in core is a prerequisite in current scenarios of 'image handling in core' (AFAIK).
But of course, getting 'external' fields in in the same movement would definitely be cool.
Doing user profiles and
Doing user profiles and image handling in core 'properly' are, to me, the big publically visible winners with this. External fields is mindblowing cool as well, but also completely new functionality as opposed to cleaning up old broken stuff. I'm personally hoping that D7 is going to be the 'cleaning up old broken stuff' release ;)
Quick side note to bio/nodeprofile confusion - looks like there's going to be consolidation of those two modules in D6 to a large extent: http://groups.drupal.org/node/8261
Other reasons for fields in
Other reasons for fields in core:
1) Allow core fields to be multiple. Example, I'd personally like to see the node->uid as a multiple value field to reflect content that has multiple authors who both need credit and rights to edit it. Node->uid could become a multiple value userreference field.
2) Provide consistent storage and handling of both core and custom fields and eliminate redundant code. Could taxonomy ultimately become a multiple value CCK field? Maybe, maybe not, but at least it might be possible.
3) Make it easier for contrib modules to extend this in ways we can't even imagine now. The content module must do its magic using nodeapi and form_alter to extend core, which limits the ways you can further extend the content module.
4) Add field-level access control to both core and custom fields.
I'm sure there are more, those are just some quick ideas.
I agree a lot on this post.
I agree a lot on this post. Fields-in-core, in a way that basically just moves and simplificates code from CCK into core, is basically a new feature for core that is already available on pretty much all Drupal sites. I mean, it would of course be cool somehow to ship with fields in the default download .. but a "Full Drupal" installation profile with cck, views etc. would /basically/ be the same for the average user.
The "content model" outlined by barry instead will actually add /new/ functionality to core, something that cannot be accomplished in contrib. And even if the patch or patches to accomplish said functionality or a variation of it might be a bit bigger and a bit harder to get into core (because it will change more stuff around than just fields-in-core, which would mainly add new code, while not necessarily changing too much of existing code), I guess the outcome will be worth the effort.
Since the beginning of the talks about Data API, it was pretty much clear that it is /not/ possibly to achieve some consisting data handling across multiple internal (sql) and external datatypes without changing or redoing (a part of) some major core API. The "content model" described by Barry seems - for me - to be an outline that would be a major step forward in Drupal being a truly flexible data processing system (read: web services), while still being something that could be accomplished in D7, still being something that does not attempt to completely rewrite most parts of core ;)
Edit: This does of course not at all mean that I am opposed to getting fields in core. Fields in core would be a great addition to Drupal, maybe already a killer feature of itself. Getting fields for both (all?) internal and also external data types into core (read: the "content model"), plus different render methods than just HTML, though, would be a killer feature that could place Drupal years in front of its competition. Imagine what could be done in contrib with that being a part of core. Drupal - the leading web 3.0 platform, anyone?
And another reason for
And another reason for fields in core is that Drupal is usually evaluated based on what it has in core. When you see comparisons of Drupal to other CMS packages or frameworks, they only compare core. Having killer features in contrib gets lost in those comparisons, we need them in core, even if to us they are things we now automatically make part of any Drupal installation. When we read reviews that compare Drupal 7 to Joomla, fields in core will be a killer feature, with or without the ability to incorporate remote content.
None of this takes away from the idea of incorporating remote content as even more of a killer feature. All of us agreed that this is great stuff that we want to get into core.
Yes and...
I think most CMS's have the ability to create basic structured content types. This is particularly important for community web sites. Having the ability to create multiple content types isn't that useful without the ability to create custom fields to add them to. We use a lot of this functionality as the core building block of commuity web sites.
I wouldn't put all field types in core, but the basics including text and select boxes, and perhaps links. I'm not sure about other fields such as images fields etc. I think the more productive conversation to have is which field types belong in core, cause they're simple enough to not need the rapidly changing code-base that Moshe is concerned (rightly so) will be stifled.
Dave