Recent posts
-
14 weeks 3 days ago
-
20 weeks 3 days ago
-
21 weeks 6 days ago
-
35 weeks 11 min ago
-
1 year 4 weeks ago
Smallcore vs Indiecore
In the smallcore debate we should focus on what our goal is. We don't want a smaller core as much as we want an independent core. To build a better teddy bear it doesn't matter so much that the openid module or blog module ship with core, but it does matter that the system or profile modules tie in with the node module, hard coded.
In his article Adrien says that "[a] large portion of time spent building something like Managing News or Open Atrium is spent undoing the assumptions that Drupal has baked into core directly." I agree with this. I don't agree that this means that we should never include a default wysiwyg in Drupal for instance. I think we should, but that it should be as a completely independent module that we can simply switch on and off. The main goal is to have a Drupal core which we don't have to alter in order to create our own distribution or highly customized site.
There will be a higher resistance against a smallcore because this means we're no longer working towards our goal of eliminating middlemen. It moves Drupal towards a framework instead of a user-friendly cms while it really can be both. If we see Drupal simply as a framework then why would we add cck or views in core instead of keeping them as a contributed modules? An independent core however would allow for the blog, openid, cck and views modules to be part of core as separate components. It means we can ship core with different installation profiles like a multiblog or a social network profile, while not getting in the way of more custom distributions like Open Atrium.
Promote this article on various sites:
Comments
More Hooks, ARRrr!
I think you hit the problem on the head. Smallcore is looking for good, clean & consistent APIs; shipping with some core modules that use those API's would be a good compromise. Having stuff hard coded in makes some people want to kill kittens (hack core). By providing an "independent core" one that has very little hard coded sounds like a good direction to take Drupal 8.
I think this is the natural progression of most software. At first you hard code in how things work, but over time one identifies the road blocks and provide smarter APIs to address the issues.
No! No! Yes!
Wim, you seem to have misunderstood what Adrian was saying in a number of ways:
"I don't agree that this means that we should never include a default wysiwyg in Drupal for instance"
No. Adrian never said this. #smallcore doesn't imply this. What Adrian said was that #smallcore would allow a wysiwyg to be included and integrated in Drupal CMS.
"It moves Drupal towards a framework instead of a user-friendly cms while it really can be both"
No. It moves Drupal towards being both.
Take away these misunderstanding's and your indiecore description *is* #smallcore
Perhaps you should re-read Adrian's article. Your post just underlines my tweet yesterday: http://twitter.com/adrinux/status/5243434018
Hi Adrian, The wysiwyg was
Hi Adrian,
The wysiwyg was just an example. When looking at the d.o issue marked as smallcore there's one for removing BlogAPI and one for removing OpenID. My point is that the removal of these modules (and thus making Drupal core smaller) have nothing to see with making Drupal core more independant. I think those two points should clearly be separated.
We're in loud agreement here
I specifically stated that we would not be changing the vision of Drupal the product.
We just need to take the API's that it is built on and split them off into a smaller, simpler to maintain base layer, that should be packaged separately.
The split in packaging is to enforce API sanity. The core needs to work completely without the CMS layer, otherwise we will just end up baking assumptions in again.
But i re-iterate here, what people download as Drupal will remain what Drupal is now. Modules that are used in the CMS will remain as actively maintained, if not more so because they will be able to advance in between releases of the drupal framework instead of being locked in stasis for 2 years at a time.
DrupalOOB
If I understand correctly the idea behind smallcore is still to move as much modules to contrib as possible, which is a valid idea. We are completely forgoing the idea of a Drupal out-of-the-box experience with a variety of default installation profiles.
I completely support the idea of API sanity and having a functionally standalone Drupal framework (the indiecore way) but I don't think this should be at the cost of DrupalOOB (the smallcore way).
Why do people keep saying this?
I blame the name "small" core, which is such a horrifically bad name it's almost comical. That's why I tend not to use it despite supporting it.
Let me make this as clear as possible: The goals of the "smallcore" movement can be obtained without removing one single module from "drupal core". If anything, the number of lines of code in "core" will likely increase, not decrease.
The "small" in smallcore has to do with the mental overhead required to get something done. See the comments in Jimmy Berry's recent blog post, in particular this one from sun and my reply. Right now, Drupal is a muddle of slightly different API approaches and half-completed work. If you want to extend something, you have to figure out how that particular system likes to be extended. Parallelism is haphazard. Lots of systems are not extensible because they're built as a one-off, meaning if you want to extend them, well, sucks to be you.
In a smallcore dreamworld, the amount of knowledge you need about Drupal becomes smaller, because it's more consistent and designed for extensibility first, not a specific use case first. With an extensible system, you can build for your use case rather than unbuilding another use case first.
Building fully generic systems can frequently take more code, not less. At least the first time. If you get that first layer right, the second layer becomes much much smaller because that first, really powerful layer is doing the bulk of the work abstractly.
The conceptual overhead of developing for and with Drupal gets smaller, not the code base (necessarily).
I get that
You are not the first to state that to obtain smallcore no module needs to be removed from core. As I've pointed out before however there are currently two module removals that are part of the smallcore movement: the removal of BlogAPI and of OpenID. And it's this removal that causes the confusion.
We are talking about exactly the same thing.
I completely support the idea of API sanity and having a functionally standalone Drupal framework (the indiecore way) but I don't think this should be at the cost of DrupalOOB (the smallcore way)
There is no difference to what you call indiecore and smallcore is. You understand exactly what it is about.
At no point in my article did i make any mention of abandoning the Drupal CMS out of the box experience, in fact the entire point of this exercise is to make it easier to develop that product and allow us to make the assumptions that need to be made for that specific use case.
It is senseless to write an API and then not have a single implementation of that API , hence Drupal CMS will be the primary application built on the framework.
You can only design a good user interface if you have the ability to make assumptions about who is going to use the interface and how. You can't freely make assumptions if the use case is 'be everything for everyone'.
There needs to be some balance.
Disclaimer: I do support #smallcore in the aspect of making Drupal core more modular, leaner and streamlined (less one-off, spaghetti code thrown together, please).
At the same time, when people say "fully generic system" that scares the hell out of me. Even when person saying this is somebody like Larry Garfield, who knows Drupal inside-out and we all respect.
It "scares" me, because I am intimately familiar with one world who has been promising "fully generic" APIs and specifications for years now: Java/J2EE. Everything abstracted, fully-annotated, and in the end - a pile of crawling mess. Frameworks like Java Server Faces are both very cumbersome, as well as SLOW. And that with bytecode running in JVM! Imagine interpreted scripting code attempting the same now.
I think we have to be very mindful of the level of generalization we really need. When Ruby On Rails came out of shadows and took infdustry by storm, one thing it had going for itself, vs Java/J2EE, was less abstraction - they made a whole bunch of common-sense decisions how things should work and removed abstraction. As a result development became much easier/faster.
jQuery has served Drupal wonderfully and being tightly integrated has provided many benefits. Nodes (in Drupal7: Fields) are essential building-blocks of Drupal. De-coupling and abstracting those-out what benefit do we really get? Is the benefit worth the added complexity and scalability/performance overhead?
How many modules/implementations do really use any other themeing engine except phptemplate? Do we really need the abstraction we've been carrying for many years now?
Can we just agree that, for now, jQuery, Nodes/Fields, Security system's basic API, PHPTemplate are #smallcore and don't need to be overriden?
One of the things about creating a microkernel implementations is the decision about: what needs to be abstracted and what is essential to the system. Basically: once you take everything out, whatever stays in the core should not be overridden. What are these things in case of Drupal?
Post new comment