|
List Info
Thread: Drupal as an API: where the value is ...
|
|
| Drupal as an API: where the value is
... |
|
2008-03-27 11:25:41 |
|
[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  garfieldte ch.com">larrygarfieldtech.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.
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 11:56:45 |
On Thu, Mar 27, 2008 at 5:25 PM, Khalid Baheyeldin
<kb2bits.com> wrote:
> On Wed, Mar 26, 2008 at 8:18 PM, Larry Garfield
<larrygarfieldtech.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
|
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 11:48:08 |
On Thu, 27 Mar 2008 12:25:41 -0400
"Khalid Baheyeldin" <kb2bits.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
|
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 12:21:17 |
|
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.
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 12:29:39 |
Quoting Chris Johnson <cxjohnsongmail.com>:
> On Thu, Mar 27, 2008 at 5:25 PM, Khalid Baheyeldin
<kb2bits.com> wrote:
>
>> On Wed, Mar 26, 2008 at 8:18 PM, Larry Garfield
<larrygarfieldtech.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/
|
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 12:34:00 |
|
On Thu, Mar 27, 2008 at 1:21 PM, catch < catch56 googlemail .com" target="_blank">catch56googlemail.com> wrote:
On Views and CCK - I think the APIs need to live in core at least.
Eventually, yes. But only when after it lives in contrib for a while (see my comment on Triggers and OpenID).
Khalid M. Baheyeldin
2bits.com, Inc.
http://2bits.com
Drupal optimization, development, customization and consulting.
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 12:35:21 |
|
On Thu, Mar 27, 2008 at 12:48 PM, Ivan Sergio Borgonovo < mailwebthatworks.it">mailwebthatworks.it> wrote:
On Thu, 27 Mar 2008 12:25:41 -0400
"Khal id Baheyeldin" < kb2bits.com">kb2bits.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.
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 12:54:48 |
On 27 Mar 2008, at 7:34 PM, Khalid Baheyeldin wrote:
> On Views and CCK - I think the APIs need to live in
core at least.
>
> Eventually, yes. But only when after it lives in
contrib for a while
> (see my comment on Triggers and OpenID).
CCK and views have been living in contrib for many many
years.
And much longer than either triggers / open id did.
And they have many more users than than either workflow or
open id did
in contrib.
And even then triggers was mostly a rewrite from workflow
(with very
different functionality), so i am not sure it could be
considered as
having gestated in contrib.
I would like any contrib module to be able to do things like
provide
default views and default content types.
|
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 14:12:51 |
On Thu, 27 Mar 2008 13:35:21 -0400
"Khalid Baheyeldin" <kb2bits.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
|
|
| Re: Drupal as an API: where the value
is ... |
|
2008-03-27 15:26:02 |
Quoting Ivan Sergio Borgonovo <mailwebthatworks.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/
|
|
|
|