Drupal as an API: where the value is ...
[New title, since it is a new topic. Was "Privatemsg needs a better maintainer".] On Wed, Mar 26, 2008 at 8:18 PM, Larry Garfield <larry@garfieldtech.com> wrote:
I would phrase it differently; core is trending toward a more engine-centric nature, with implementations built on top of it in contrib. Since the engines are the harder code and usually contain the trickier bugs, that actually works out. The really complex/ugly stuff goes through the core gauntlet, while contrib can, hopefully, get smaller and simpler as it's just ways to piece together or tweak the engines.
At least that's what I hope is happening / will happen. :-)
On Wednesday 26 March 2008, FGM wrote:
Note that coupling this observation with the trend towards a leaner, more feature-limited core, makes the value proposition of drupal more problematic: if core unbundles features to contrib in order to obtain a better and more performing core, contrib cannot but remain of lower quality, and the overall value to potential users becomes lower between a small and excellent core, and a haphazard mix of contrib modules, only some of which are of quality comparable with core.
I am in the camp that core should be more about APIs, than ready to use stuff. How these APIs are used should be left for contrib. Contrib has been an innovation test bed for Drupal. Many of the "applications" and even interesting frameworks have been in contrib. Think of ecommerce/ubercart and CiviCRM: those are what people use and want. Think about Views and CCK, and if they were in core: would they develop so quickly with core being only committed to by a few people? Things that have proven themselves in contrib become candidates for core, and this happened already for OpenID and Triggers. They were easier and faster to prototype, test, mature and then they go into core. Look at how many Feed/Aggregator we have now? Hopefully soon they will consolidate into one good thing that makes it to core. Core should not be bloated with "applications" where there are more than one way of doing things, and people would never agree on the right way. It should provide some basic modules, yes, but not more functionality in core that can be covered by contrib in more than one way. So, the value of Drupal core is in providing powerful, flexible and clean APIs, letting contrib run wild with them, then selectively taking pieces back in core to become enablers for more innovation in the future, whether they are APIs or applets or whatever. This strategy has worked well for us, and there is no reason to change it for the time being, unless the landscape changes and it requires changes. For me, Drupal is a web application framework, and that is where its power is. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Thu, 27 Mar 2008 12:25:41 -0400 "Khalid Baheyeldin" <kb@2bits.com> wrote:
For me, Drupal is a web application framework, and that is where its power is.
+1 even if I'd underline that if it was a pure framework it wouldn't be so successful. I think Drupal still have to remain the core of self-sufficient application, not a library on which to build. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Thu, Mar 27, 2008 at 12:48 PM, Ivan Sergio Borgonovo < mail@webthatworks.it> wrote:
On Thu, 27 Mar 2008 12:25:41 -0400 "Khalid Baheyeldin" <kb@2bits.com> wrote:
For me, Drupal is a web application framework, and that is where its power is.
+1 even if I'd underline that if it was a pure framework it wouldn't be so successful.
I think Drupal still have to remain the core of self-sufficient application, not a library on which to build.
Agreed. If only that the modules in core allow a basic blog or site, and demonstrate how to use the API. We are not CakePHP, Qcodo or Django in PHP. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Thu, 27 Mar 2008 13:35:21 -0400 "Khalid Baheyeldin" <kb@2bits.com> wrote:
Agreed.
If only that the modules in core allow a basic blog or site, and demonstrate how to use the API.
We are not CakePHP, Qcodo or Django in PHP.
I didn't want to make comparisons but you stole my words. Since we are at it Drupal is not Joomla, XOOM, Xaraya on the other side. Making Drupal a self-sufficient application make the difference between having specialised libraries and have a CMS RAD. Still I'd like Drupal move more in the direction of Django rather than on the other side. Some months ago this topic came out with another face, and people were discussing the importance of being a premier blog app. Honestly even if I still think Drupal is the best on its category, things like comments, blogs, forums comes in to the way more than what they may help for many use case. Drupal couldn't live without an out-of-the-box working blog, forum etc... but I'd like to see these things getting more modularised in their features so that a default install would be "slimmer" with default setup. Still if the process of modularising what Drupal offers will make it lose some features in the process I think it will have a high cost in user base. So before stuff can be kicked out of core there should be such a nice API that will make trivial to rebuild what's in core now and may find a better place in contrib. Then anyone that would like some "non trivial" stuff... will just go a step further. And maybe the actual blog/forum etc... implementation will just be part of the API documentation to "demonstrate" how it works. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
So before stuff can be kicked out of core there should be such a nice API that will make trivial to rebuild what's in core now and may find a better place in contrib.
Don't we have that with the installation profile[1]? We use that to help modify the project module create distributions based on the profile so that the required and suggested modules can be rolled into the distribution. [1] http://drupal.org/project/Installation+profiles Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Thu, 27 Mar 2008 16:26:02 -0400 Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
So before stuff can be kicked out of core there should be such a nice API that will make trivial to rebuild what's in core now and may find a better place in contrib.
Don't we have that with the installation profile[1]? We use that to help modify the project module create distributions based on the profile so that the required and suggested modules can be rolled into the distribution.
I meant: before support for features currently into core, leave it and move into contrib, the core API to support those features should be so lovely that writing a "reference" implementation of the feature should be trivial. On the other side I think that stuff like Views and Panels should have a place into core[1] but as an API and not as an implementation of a feature. They shouldn't move into core until they look more like an API rather than an implementation otherwise as it has been said they risk to slow down core and make it a mess. [1] I don't think CCK should stay into core -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Thu, Mar 27, 2008 at 5:25 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Wed, Mar 26, 2008 at 8:18 PM, Larry Garfield <larry@garfieldtech.com> wrote:
I would phrase it differently; core is trending toward a more engine-centric nature, with implementations built on top of it in contrib.
I am in the camp that core should be more about APIs, than ready to use stuff. How these APIs are used should be left for contrib.
Think about Views and CCK, and if they were in core: would they develop so quickly with core being only committed to by a few people?
I think I'm in agreement with Khalid. I'd prefer to see Views and CCK, and the like, live outside of core. Instead, core should evolve to support and enable most anything the Views and CCK developers might dream up if it looks extensible to other ideas and modules, but not actual provide the functionality. I definitely agree with the thinking that Drupal is a web application framework, and that is what makes it so powerful and popular. ..chris -- Chris Johnson http://tinpixel.com
Quoting Chris Johnson <cxjohnson@gmail.com>:
On Thu, Mar 27, 2008 at 5:25 PM, Khalid Baheyeldin <kb@2bits.com> wrote:
On Wed, Mar 26, 2008 at 8:18 PM, Larry Garfield <larry@garfieldtech.com> wrote:
I would phrase it differently; core is trending toward a more engine-centric nature, with implementations built on top of it in contrib.
I am in the camp that core should be more about APIs, than ready to use stuff. How these APIs are used should be left for contrib.
Think about Views and CCK, and if they were in core: would they develop so quickly with core being only committed to by a few people?
I think I'm in agreement with Khalid. I'd prefer to see Views and CCK, and the like, live outside of core. Instead, core should evolve to support and enable most anything the Views and CCK developers might dream up if it looks extensible to other ideas and modules, but not actual provide the functionality.
I definitely agree with the thinking that Drupal is a web application framework, and that is what makes it so powerful and popular.
I live in this camp as well. I use Drupal as an API to feed the data to the CMS portions of Drupal. However there are still ideas created in contributions that are better served from within the Drupal API framework; ahah_forms for example. Not all content fits nicely in one blob node->message so others created CCK; I'm not sure I agree or disagree about its inbreeding into the core structure. I lean toward agreeing that it should be a part of core perhaps pulling the node->message and node->teaser into CCK as field types. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Mar 27, 2008, at 11:56 AM, Chris Johnson wrote:
I think I'm in agreement with Khalid. I'd prefer to see Views and CCK, and the like, live outside of core. Instead, core should evolve to support and enable most anything the Views and CCK developers might dream up if it looks extensible to other ideas and modules, but not actual provide the functionality.
The problem comes when certain concepts and tools have become so integral to the operation of most Drupal sites that they are, effectively, part of core. Internationalization is important, for example, but how many sites are internationalized vs. using Views? Obviously, "lots of people use it, it should be in core" isn't a good approach to take. But key concepts, like the use of metadata-driven content listings and "fields" as the basic unit of information storage for content, sometimes need to make it into core for the rest of the community to continue evolving. --Jeff
Jeff, That's pretty much my thinking, too. We may disagree only on fine points and where the actual line is drawn. Internationalization capabilities need to be in core, but providing the translations and localizations are not part of core. The ability to have a Views and CCK, the key enabling technologies, need to be in core, but all the bells and whistles of actually using those features probably should not. CCK is great for quickly and easily creating new content types, but if I don't want the software bloat and inefficiencies that go with it, I shouldn't have to have that code as baggage in core if I don't use it. Core should be lean and mean. ;-) ..chris On Fri, Mar 28, 2008 at 5:33 PM, Jeff Eaton <jeff@viapositiva.net> wrote:
The problem comes when certain concepts and tools have become so integral to the operation of most Drupal sites that they are, effectively, part of core. Internationalization is important, for example, but how many sites are internationalized vs. using Views?
Obviously, "lots of people use it, it should be in core" isn't a good approach to take. But key concepts, like the use of metadata-driven content listings and "fields" as the basic unit of information storage for content, sometimes need to make it into core for the rest of the community to continue evolving.
--Jeff
This ties in with a few things I've been thinking about recently. I posted something on groups a while back that's along similar lines: http://groups.drupal.org/node/6143 Couple of updates to that: At the unit testing BOF in Boston, Douglas Hubler brought up one possibility opened up by having core covered by testing. When there's a high level of test coverage, it ought to be fairly easy to maintain a development version of smaller contrib modules as soon as code thaw starts, have tests for it, run those tests every couple of weeks, and then be told exactly what APIs have been broken week by week. Have a couple of dozen modules maintained like that, and you'd be able to run skeleton sites using a few contrib modules on HEAD all the way up through to Beta and RC (obviously with no content upgrade path). The more APIs move into core, the more of contrib could potentially do this. This combined with packaged install profiles would release a lot of the need to keep modules in core - since we'd have regression tests (== poll module) in contrib being broken every so often during the release cycle to keep us honest, and an easy way for new users to get started with some basic modules that could potentially be ready at the same time as core moves to RC. This has a decent chance of improving upgrade documentation and automated tools like coder as well - meaning less of a lag between major releases and contrib upgrades. In terms of the lack of reviews in contrib, IMO this is an issue that needs more discussion. I don't maintain any contrib modules, none at all, but I try to help out on the issue queues for ones I use. Even though less people use contrib modules than core by default, the number of eyes on the queues for big modules like CCK and views is proportionally much, much lower. Additionally, lots of traffic about modules (including bug reporting and fixing) happens in the support forums rather than issue queues and gets lost there. I know sepeck is in the process of reorganising the forums - which will include more pointers to individual module issue queues for that sort of help - and it'd be good long term to get module-specific questions (and answers) out of the forums so they're kept in one place. Something that might help with visibility for support requests in contrib would be an "open support requests" link from contributors links to encourage people to help out on modules they don't personally maintain - similar to the function 'new forum topics' has now. This means moving real people from the forums to issue queues - if even 10% of the people who move are those who already answer questions and test fixes in the forums - it could mean many, many more reviewers both for core and contrib (and possibly less work for module maintainers rather than more). On Views and CCK - I think the APIs need to live in core at least. Core currently has to implement a bunch of stuff that CCK and views does (fields, formatters, lists of stuff all over the place) - so unless we can have core depending on contrib, it's a lot of duplicate code. Whether that includes the UI for adding fields and creating new views is a different matter.
participants (6)
-
catch -
Chris Johnson -
Earnie Boyd -
Ivan Sergio Borgonovo -
Jeff Eaton -
Khalid Baheyeldin