Well, I was writing this as a reply to a reply to the previous 'Encouraging collaboration' thread, but it's grown too big, so sorry, but I want to open a new thread. A "great developer platform" is how I see Drupal, and I'm sure most of the developers too. But the thing is: we need some focus, some targets to agree on. The problem is: currently we are pretending Drupal -core- to be too many things at the same time, mostly that great developer platform (1), but also an out of the box ready to use community portal (2) or kind of that. And the consequence is we are handling too many issues when fixing bugs for 'Drupal core' that are too specific of some more 'user level, site specific' modules. The main point is *core shouldn't need to be an out of the box nice site* that anyone can use, and we need to jump in the *one core, many distributions* idea for that. And that need to be an out of the box nice site is actually consuming far more effort than what could be a proper CMS core. IMHO we are wasting efforts in some higher level modules, that should be more focused to get what is properly the core system working right in the first place. And I'm not making any judgement about which modules should be in core and which ones not. I mean,, ok to have a few nice modules in core, but when a module grows too much, because people wants all that nice features, and them to be easy to set up, we can a) move it out of 'core' or b) provide a basic one in core that can be extended by a contrib module. Just as an example -and I have nothing against forum module: At some point, we are duplicating the taxonomy interface to handle a forum specific vocabulary. Then, this causes some bug -like this one, again just an example: http://drupal.org/node/24274 -, and then we have a *core bug*, module specific, but as it is a core module, this one has the same importance -in the bug tracking system- as any other critical bug -like a basic API not working properly. Notice that on one side we have a very big module in core to handle forums, but on the other side we don't have an small one for what could be a badly needed feature for other modules to build upon: a basic image node module. -again just an example, but I'm not talking about forum vs image at all. And as a side effect... How many modules you need to patch for what could be a small 'core patch' -if core was smaller- before your patch can be even considered because you can say at least 'it applys to HEAD' ?? And how many modules you need to re-patch again because of a minimum detail has changed in the main core patch during the follow up on the issue tracker? So I want to insist on the idea of "many distributions to serve different sites, one core to serve them all" --nice 'mantra', isn't it? ;-) But, anyway, that's an old idea. Just look at Linux.... Could you install 'Linux' --properly understood as the core OS- and pretend you have a nice OS ready to play with your computer? Cheers, Jose -- Jose A. Reyero http://www.reyero.net
The problem is: currently we are pretending Drupal -core- to be too many things at the same time, mostly that great developer platform (1), but also an out of the box ready to use community portal (2) or kind of that. And the consequence is we are handling too many issues when fixing bugs for 'Drupal core' that are too specific of some more 'user level, site specific' modules.
Without a doubt, blog or aggregator is not the same level of functionality as node or taxonomy not to mention the required modules. Here is a proposed core set: block comment filter help locale (because this lets you change strings so its always useful) menu node path search story system taxonomy throttle upload user watchdog (hope I have not missed any required ones :) ) Regards NK
OK, I like Karoly's list of core minimum modules a lot better than mine. :-) I'd recommend using page as the stock nodetype rather than story, but otherwise yeah, this is the core list, not the one on my email. :-) On Saturday 19 November 2005 12:52 pm, Karoly Negyesi wrote:
Without a doubt, blog or aggregator is not the same level of functionality as node or taxonomy not to mention the required modules.
Here is a proposed core set:
block comment filter help locale (because this lets you change strings so its always useful) menu node path search story system taxonomy throttle upload user watchdog
(hope I have not missed any required ones :) )
Regards
NK
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Yup great one, again, Charlie! I love the fact satistics is not there; I would say path has to go too (in favour of a more complete, pathauto combination, lliving in contribs) Op zaterdag 19 november 2005 20:33, schreef Larry Garfield:
OK, I like Karoly's list of core minimum modules a lot better than mine. :-) I'd recommend using page as the stock nodetype rather than story, but otherwise yeah, this is the core list, not the one on my email. :-)
On Saturday 19 November 2005 12:52 pm, Karoly Negyesi wrote:
Without a doubt, blog or aggregator is not the same level of functionality as node or taxonomy not to mention the required modules.
Here is a proposed core set:
block comment filter help locale (because this lets you change strings so its always useful) menu node path search story system taxonomy throttle upload user watchdog
(hope I have not missed any required ones :) )
Regards
NK Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Interesting that you'd mention that. Pathauto currently has some unpleasant snafus (goofy things happen when your rules generate the same alias for an 'index' and a taxonomy term, for example)... but the combination of path and pathauto are so essential that I can't imagine any site not wanting to use them. -----Original Message----- From: Bèr Kessels [mailto:ber@webschuur.com] Sent: Saturday, November 19, 2005 1:51 PM To: development@drupal.org Subject: Re: [development] One core, many distributions Yup great one, again, Charlie! I love the fact satistics is not there; I would say path has to go too (in favour of a more complete, pathauto combination, lliving in contribs)
I've only toyed with pathauto a little, but found it a bit quirky. It liked to put '0' at the end of names, and the underscores in names is highly ugly. I'm also not overjoyed about the visable path list suddenly becoming gigantic. If I have 1000 users, do I REALLY want 1000 visable path aliases listed in admin/path? I don't. :-) Either way, I think we can all agree that a "human-friendly URL-making thingie module" should be one of the reduced core modules, whichever it ends up being. That's something to deal with later. On Saturday 19 November 2005 01:58 pm, Jeff Eaton wrote:
Interesting that you'd mention that. Pathauto currently has some unpleasant snafus (goofy things happen when your rules generate the same alias for an 'index' and a taxonomy term, for example)... but the combination of path and pathauto are so essential that I can't imagine any site not wanting to use them.
-----Original Message----- From: Bèr Kessels [mailto:ber@webschuur.com] Sent: Saturday, November 19, 2005 1:51 PM To: development@drupal.org Subject: Re: [development] One core, many distributions
Yup great one, again, Charlie!
I love the fact satistics is not there; I would say path has to go too (in favour of a more complete, pathauto combination, lliving in contribs)
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Well, I didn't want to start a discussion about which modules should be in core, and which ones shouldn't. But it seems I did anyway :-( Bèr Kessels wrote:
Yup great one, again, Charlie!
I love the fact satistics is not there; I would say path has to go too (in favour of a more complete, pathauto combination, lliving in contribs)
Op zaterdag 19 november 2005 20:33, schreef Larry Garfield:
OK, I like Karoly's list of core minimum modules a lot better than mine. :-) I'd recommend using page as the stock nodetype rather than story, but otherwise yeah, this is the core list, not the one on my email. :-)
On Saturday 19 November 2005 12:52 pm, Karoly Negyesi wrote:
Without a doubt, blog or aggregator is not the same level of functionality as node or taxonomy not to mention the required modules.
Here is a proposed core set:
block comment filter help locale (because this lets you change strings so its always useful) menu node path search story system taxonomy throttle upload user watchdog
(hope I have not missed any required ones :) )
Regards
NK
Bèr
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 9:33 PM, Larry Garfield wrote:
path
I agree, but I believe that pathauto like functionality should be part of our default install, and we should emphasise it. It's one of our more powerful features, and the improvements in usabilty and browsability are amazing. Plus google loves you much much much more. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf4NrgegMqdGlkasRAjiCAKDUArqbsVsS22qKTNYJy2YZqw+lPgCgiZlz 3fHwmUKLRNcZlOOgdbrAdLo= =TK/S -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
I agree, but I believe that pathauto like functionality should be part of our default install, and we should emphasise it. It's one of our more powerful features, and the improvements in usabilty and browsability are amazing. Plus google loves you much much much more.
Okay - people have lost their minds (sorry don't mean to single you out here Adrian - especially considering your comments later on in this thread - and all the work that you do, but this comment just floored me enough to end months of silence). What floored me is the irony that the topic should come up in a thread about creating a leaner core that can support multiple distributions. Path auto is the epitome of a contributed module. It serves a purpose that many people may find useful, but is NOT REQUIRED and does not serve a CORE purpose. (Core module = module absolutely required to make the software/development environment work.) I've more or less given up trying to define what Drupal is. Its a lot of things to a lot of different people. (I'm finally coming around to thinking of it as two distinct things: 1) a rapid software development platform 2) a Drupal Branded CMS that uses has the rapid software development platform at its core). But I can define what Civicspace is - I can define what DrupalArt is - I can define what Drupal Blog is - I can define what DrupalEd is etc. And I know that Drupal is at the CORE of all of them. So I'm in full agreement with Jose's idea of 'one core to serve them all'. If something doesn't 'serve them all' it has no place in core. Take this idea to its logical conclusion and Forum.module should be dropped from core. "HERESY!!!," the masses rise up and shout. "That's where drupal all began. BURN THE HERETIC." Fine - light your torches - but when your done and Drupal 5.0 comes out with a full installer that starts with a lean core and adds only whatever users need and/or want - you'll realize that your already on the same page. andre p.s. As for multiple contributed modules that do more or less the same thing. If people don't want to work together it doesn't matter. Natural selection will take place. Competition is good. The module that adapts the quickest to the needs of the community will become the defacto standard - until a new competitor comes along. Why did someone write Drupal when there was another forum tool available at the time? Why do people improve Drupal when they could be working on phpNuke ;-)? The multiple contrib module issue is a non-issue.
"HERESY!!!," the masses rise up and shout. "That's where drupal all began. BURN THE HERETIC."
Could you please show me forum module in my list? http://lists.drupal.org/pipermail/development/2005-November/011429.html Of course forum is not core. What should be in core? Required modules and those that have a fairly extensive API.
Karoly Negyesi wrote:
"HERESY!!!," the masses rise up and shout. "That's where drupal all began. BURN THE HERETIC." Could you please show me forum module in my list?
http://lists.drupal.org/pipermail/development/2005-November/011429.html
Of course forum is not core.
What should be in core? Required modules and those that have a fairly extensive API.
Agreed - I wasn't commenting on your list. I was commenting on what Jose said:
Just as an example -and I have nothing against forum module: At some point, we are duplicating the taxonomy interface to handle a forum specific vocabulary. Then, this causes some bug -like this one, again just an example: http://drupal.org/node/24274 -, and then we have a *core bug*, module specific, but as it is a core module, this one has the same importance -in the bug tracking system- as any other critical bug -like a basic API not working properly.
andre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20 Nov 2005, at 11:21 PM, Andre Molnar wrote:
Path auto is the epitome of a contributed module. It serves a purpose that many people may find useful, but is NOT REQUIRED and does not serve a CORE purpose.
User-friendliness is a core purpose imo. I believe being able to create human readable URL's automatically is something we should build upon wherever possible. I also think we should turn pathauto into more of an API, so modules / nodes / pages can expose properties to be used in url's. I also believe we should never ever show a node id to an end user. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgQOdgegMqdGlkasRAkkiAJ9Q2lD2IRoAgqhiN0GYSr1PFRqDxQCgmyEh kQenWdx41vN6dcj3hVUlGz8= =FQZK -----END PGP SIGNATURE-----
On 11/20/05, Adrian Rossouw <adrian@bryght.com> wrote:
I believe being able to create human readable URL's automatically is something we should build upon wherever possible. I also think we should turn pathauto into more of an API, so modules / nodes / pages can expose properties to be used in url's.
I also believe we should never ever show a node id to an end user.
+1, IMHO, pathauto is one of the most useful druapl modules, it really should be in core.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov 2005, at 1:24 AM, andrew morton wrote:
+1, IMHO, pathauto is one of the most useful druapl modules, it really should be in core.
Also.. keep in mind we probably don't mean the actual pathauto module.. more like the gist (functionality) of it, integrated properly into the current path module. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgQbBgegMqdGlkasRAm48AKCmIP4q+WqdCcxH43ERGDPuEZ/hkACgjVLg Q/GYg1ijzXUAGCVJy/1lqvA= =6e+X -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 20 Nov 2005, at 11:21 PM, Andre Molnar wrote:
Path auto is the epitome of a contributed module. It serves a purpose that many people may find useful, but is NOT REQUIRED and does not serve a CORE purpose. User-friendliness is a core purpose imo.
I believe being able to create human readable URL's automatically is something we should build upon wherever possible. I also think we should turn pathauto into more of an API, so modules / nodes / pages can expose properties to be used in url's.
I also believe we should never ever show a node id to an end user.
I hate software that tries to think for me. (If another word processing program dares to, by default, capitalize something that I didn't capitalize to begin with - or another IDE, by default, adds so much as a line break to my code - or if any software suggests another file name for me when I go to save - so help me god I'm going to... ... fume because there's nothing else I can do). How can we as developers presume to KNOW how the end user wants to see their URL's? And if the user / developer wants to change the default 'human readable' URL, they will still have to turn to path-alias or another path tool to do so AND/OR hack some code to do it (API or no API). What have we gained?
Also.. keep in mind we probably don't mean the actual pathauto module..
more like the gist (functionality) of it, integrated properly into the current path module.
Yes - I assumed that - considering pathauto does an okay job - but is still a bit glitchy. And don't get me wrong - path auto is fine and is a nice feature that should make it into several distributions of Drupal - but if I don't want it - or I want to bake my own way of auto aliasing paths that should be left up to me. andre p.s. Am I the only one that sees beauty in the simplicity of example.com/node/13 meaning the 13th node of content on a site - and node/1000345 being the 1,000,345th node on a site... and am I the only one that thinks 1 million aliases might be a bit silly to generate automatically?
On Sunday 20 November 2005 09:30 pm, Andre Molnar wrote:
Adrian Rossouw wrote:
I also believe we should never ever show a node id to an end user.
I hate software that tries to think for me. (If another word processing program dares to, by default, capitalize something that I didn't capitalize to begin with - or another IDE, by default, adds so much as a line break to my code - or if any software suggests another file name for me when I go to save - so help me god I'm going to... ... fume because there's nothing else I can do). How can we as developers presume to KNOW how the end user wants to see their URL's?
Agreed. Some are obvious. (Eg, user/username vs. user/userid is a no-brainer that's easy to code and isn't being "smarter" than the user.) Others, I dare say most, are not.
p.s. Am I the only one that sees beauty in the simplicity of example.com/node/13 meaning the 13th node of content on a site - and node/1000345 being the 1,000,345th node on a site... and am I the only one that thinks 1 million aliases might be a bit silly to generate automatically?
See, my problem with pathauto is not the auto-generation, it's that putting 1 million entries into the path_alias table is going to kill your system. Of course at that point, the numbers make more sense anyway (or some other numeric format, like issue # and then article # for a magazine, but still numeric). Really, though, I'm trying to avoid thinking of new and cool things for Drupal until after 4.7 ships. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
See, my problem with pathauto is not the auto-generation, it's that putting 1 million entries into the path_alias table is going to kill your system. Of course at that point, the numbers make more sense anyway (or some other numeric format, like issue # and then article # for a magazine, but still numeric).
Really, though, I'm trying to avoid thinking of new and cool things for Drupal until after 4.7 ships. :-)
who says that they all need to go into a table? it is plausible to use an url strategy like article/mytitle. when drupal receives that request, it does a node_load(array('title' => mytitle));
Moshe Weitzman wrote:
See, my problem with pathauto is not the auto-generation, it's that putting 1 million entries into the path_alias table is going to kill your system. Of course at that point, the numbers make more sense anyway (or some other numeric format, like issue # and then article # for a magazine, but still numeric). Really, though, I'm trying to avoid thinking of new and cool things for Drupal until after 4.7 ships. :-)
who says that they all need to go into a table? it is plausible to use an url strategy like article/mytitle. when drupal receives that request, it does a node_load(array('title' => mytitle));
But then you make title a unique field...
On Mon, 2005-11-21 at 08:00 -0800, Vernon Mauery wrote:
Moshe Weitzman wrote:
See, my problem with pathauto is not the auto-generation, it's that putting 1 million entries into the path_alias table is going to kill your system. Of course at that point, the numbers make more sense anyway (or some other numeric format, like issue # and then article # for a magazine, but still numeric). Really, though, I'm trying to avoid thinking of new and cool things for Drupal until after 4.7 ships. :-)
who says that they all need to go into a table? it is plausible to use an url strategy like article/mytitle. when drupal receives that request, it does a node_load(array('title' => mytitle));
But then you make title a unique field... Or display a list of all nodes+teasers with the same title
While discussing what to ship with core I'd like to reiterate my vote to move the drupal.module to the contributions repository for this release. There are very few good uses of the "Drupal sites" feature, and the distributed login is, imo, a security risk. http://drupal.org/node/31716 -Robert
On 21-Nov-05, at 2:31 PM, Robert Douglass wrote:
While discussing what to ship with core I'd like to reiterate my vote to move the drupal.module to the contributions repository for this release. There are very few good uses of the "Drupal sites" feature, and the distributed login is, imo, a security risk.
Once we take it out, it's hard to get back in, especially as we talked about the various "phone home" features to gather statistics on installed modules. I would be in favour of keeping the hooks for login/authentication maintained within the drupal module, and the actual *implementation* moved to something like drupalauth.module. Or we could just fix it :P -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
Boris Mann wrote:
I would be in favour of keeping the hooks for login/authentication maintained within the drupal module, and the actual *implementation* moved to something like drupalauth.module.
+1
Or we could just fix it :P
-- Neil Drumm http://delocalizedham.com/
On Nov 20 2005, at 10:30 PM, Andre Molnar wrote:
p.s. Am I the only one that sees beauty in the simplicity of example.com/node/13 meaning the 13th node of content on a site - and node/1000345 being the 1,000,345th node on a site... and am I the only one that thinks 1 million aliases might be a bit silly to generate automatically?
yes.
Op maandag 21 november 2005 07:08, schreef Liza Sabater:
the only one that thinks 1 million aliases might be a bit silly to generate automatically?
yes.
No Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Nov 2005, at 10:15 AM, Bèr Kessels wrote:
Op maandag 21 november 2005 07:08, schreef Liza Sabater:
the only one that thinks 1 million aliases might be a bit silly to generate automatically?
yes.
No
There will only (really) ever be as many aliases as you have nodes / users. If you have 1 million nodes/users, you have for more problems than the path_alias table. The path alias table is really simple, and we improved the performance a ton, so it only loads aliases as needed (instead of caching all of them the whole time) The unicode problem is a good one though. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDgYOFgegMqdGlkasRAiP6AKCnxdCITcwYoRWRGAn5cYWFv1wX+gCfefa7 0Jo1oAkPtPCULPhaVB4u/1Y= =XFCl -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
There will only (really) ever be as many aliases as you have nodes / users.
If you have 1 million nodes/users, you have for more problems than the path_alias table.
The path alias table is really simple, and we improved the performance a ton, so it only loads aliases as needed (instead of caching all of them the whole time)
Well, we try to find an alias for every link and end up sending at least a few dozen requests to that table per page view. I'd still like to see this more centralized so we can get away with less queries. Cheers, Gerhard
Op maandag 21 november 2005 09:21, schreef Adrian Rossouw:
On 21 Nov 2005, at 10:15 AM, Bèr Kessels wrote:
Op maandag 21 november 2005 07:08, schreef Liza Sabater:
the only one that thinks 1 million aliases might be a bit silly to generate automatically?
yes.
No
There will only (really) ever be as many aliases as you have nodes / users.
If you have 1 million nodes/users, you have for more problems than the path_alias table.
The path alias table is really simple, and we improved the performance a ton, so it only loads aliases as needed (instead of caching all of them the whole time)
No, nAliases = nPages = nNodes + (nUsers * 2) + (nTags ^ nTags) + (nByModules) (nByModules, for tagadelic, 2 * (nVocabularies ^ 25), or for image: nImages + nGalleries) so, nAliases can be enourmous, humongous, redicoulous big, if this is to be used, we need to follow Moshes road of 'dynamic' aliases, i.e. aliases made on-the-fly. That is, what I wanted to do for tagadeli. So, not store /tagadelic/chunk/Foo, /tagadelic/chunk/Foo+Bar /tagadelic/chunk/Foo,Bar /tagadelic/chunk/Foo+Faa and so on, but rather just match Foo, Faa, Bar against the db on call of that page. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Actually, I'd suggest something even easier. In 4.7, there's a menu settings fieldset for every node. First, expand that to tie to just ONE menu instead of all of them, for size reasons. Call that menu "Site Structure" (or "Navigation" <g>). Then any page that gets put into that menu automagically gets a dynamic alias (read: not stored in path_alias) of that menu location. So a node with ID 47 called "stuff" that is placed in the menu with parent: Site Menu > mysection > mysubsection will be accessible via both node/47 AND mysection/mysubsection/stuff. That way the node_alias table doesn't get hammered, there's a clean interface to it, it makes logical sense for a deep site structure as well as a shallow one, and you also get to leverage all of the menu module magic. In fact, set that site menu to be the Primary Links menu, thanks to Richard's great new patch, and you automagically get your primary and secondary links based on your URLs. (If you don't want them to be, though, you don't have to.) That should scale as large as large as sites that need a unique non-numeric name for everything. (Eg, drupal.org has no need to give a string name to every single node.) The path module can stay as is for adding additional paths to a page if needed (say, the diffandpatch page which we do want to have a nice short URL but doesn't belong in the primary links), but won't be necessary for most "normal" pages. usernames, frankly, should be a built-in feature. It should be trivial to tweak user.module to accept an ID or name, since both are required to be unique anyway. Besides, path_alias doesn't scale for larger sites. (Drupal.org has over 40,000 users, if I'm interpreting the URL correctly. pathauto would die horribly.) That eliminates the two largest needs for path/pathauto. The rest are taxonomy categories, which could also be automated the same was as user, or not, take your pick. :-) Either way it would clean up the largest needs for path/pathauto, and offer additional functionality. I think it's too late to put that into 4.7, but what do you think? On Monday 21 November 2005 02:43 am, Bèr Kessels wrote:
So, not store /tagadelic/chunk/Foo, /tagadelic/chunk/Foo+Bar /tagadelic/chunk/Foo,Bar /tagadelic/chunk/Foo+Faa and so on, but rather just match Foo, Faa, Bar against the db on call of that page.
Bèr
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 11/21/05, Larry Garfield <larry@garfieldtech.com> wrote:
Actually, I'd suggest something even easier. In 4.7, there's a menu settings fieldset for every node. First, expand that to tie to just ONE menu instead of all of them, for size reasons. Call that menu "Site Structure" (or "Navigation" <g>). Then any page that gets put into that menu automagically gets a dynamic alias (read: not stored in path_alias) of that menu location. So a node with ID 47 called "stuff" that is placed in the menu with parent:
Site Menu > mysection > mysubsection
will be accessible via both node/47 AND mysection/mysubsection/stuff.
I've played around with this idea of "dynamically constructed URLs" quite a bit in Drupal, and my conclusion, at the end of the day, is that they're more trouble than it's worth. The biggest problem is performance: the URL is parsed IN easily, because only the part after the last slash ('/') needs to be processed; but when the URL gets printed OUT (i.e. through the url() or l() function), the system has to crawl up the menu tree, from the current page through all its parents, and find the URL for each ancestor before joining them all together with slashes. This is how my own site's URL handling system works - I developed it just before pathauto came out (almost a year ago!) - you can read all about it in my article: http://www.greenash.net.au/posts/thoughts/hierarchical_url_aliasing The above URL is an example that shows the performance problems I was just talking about. Another problem is unique URLs: with constructed URLs, every part of the URL (where a 'part' is the bit between each slash) has to be unique for every URL on the site - this problem can be avoided, but only with even more sacrifice in performance. Basically, I consider my approach of constructing URLs by walking up the menu tree to be the wrong approach, particularly if performance is critical and the site has many nodes. Despite seeming 'less right' (IMO), the pathauto approach of static aliases is simpler and scales better. It also fits in with the current core system, whereas my approach requires patching the core in order to work. Although I'm a huge fan of pathauto, and of Drupal's support for configurable URLs in general, I don't think that pathauto belongs in core. I also don't agree with the idea that users should never see a node ID: this is like saying that book readers should never see an ISBN, or that people who buy electronics should never see the model number. Like these things, a node ID is sometimes useful, even for an end user; but also like these things, a node ID should be made as inconspicuous as possible, and it should still be there for users that look for it. Rather than moving pathauto to core, I'd like to keep in the spirit of Adrian's "API fever", and suggest that a "path API" would be a better alternative for core. This would allow more advanced features, such as overriding path aliases, bringing back the conf_url_rewrite() type functionality (or has it never left?), etc. Jaza.
Liza Sabater wrote:
On Nov 20 2005, at 10:30 PM, Andre Molnar wrote:
p.s. Am I the only one that sees beauty in the simplicity of example.com/node/13 meaning the 13th node of content on a site - and node/1000345 being the 1,000,345th node on a site... and am I the only one that thinks 1 million aliases might be a bit silly to generate automatically?
yes.
I prefer a dev list with as little noise as possible, but in this case, I think this needs to be said: No, Andre is not the only sees that simplicity and not the only who thinks 1 million automatic aliases might be silly. I agree with Andre. Liza seems to be saying "yes, Andre is the only one who thinks that way" but perhaps it was just sloppy use of English and she meant "yes, I agree with Andre." ..chrisxj
On Nov 21 2005, at 11:50, Chris Johnson wrote:
Liza seems to be saying "yes, Andre is the only one who thinks that way" but perhaps it was just sloppy use of English and she meant "yes, I agree with Andre."
Heh. No, I did mean the first meaning. Don't get me wrong, I love most of the time how software developers think. It's sexy, but just like a lot of sexy stuff out there, it has somewhat to do with reality :) The way regular, non-software developers use Drupal seems to be very different from the way you guys conceive of it. I personally do not care about the url BUT the reality is that you will most likely get faster indexing of your sites by bots --and better stumble upon traffic-- if you have verbose links as opposed to those "node/ doohickey/numbers" system. It's not your fault or the users, it's just is. So having flexibility on how those links are created, right off the bat, is what Drupal ought to be striving for. Look, someone did a really bad, and I mean, really HORRIDLY BAD call when they decided to take out the sessions setting options for the 4.6 release. It was in 4.5, my site never logged me out and it seemed that a lot of people found it useful as well. Not only did y'all take it out, but it is nowhere stated in your documentation that this was taken out. And not only did you take it out but, guess what, a lot of people have grumbled about this on the support list (or so it seems), because it was not announced nor was there an option offered to deal with potential log-out problems. I had 5 people look at this problem on my site and one of them came across this story by diving into your support archives. And you did changes to the RSS system as well, and not for the good of the user but for the good of your geekatude. Rule #1 : If it aint broke, dont fix it. You broke so many rules about market strategy, usability and software development, I can't even fathom how you came to the conclusion this was a good idea. Then again, yes, I can fathom the logic just by the discussion we are having here. You think about the beauty of the code, the simplicity of your logic. That's nice and good. The problem is that it has nothing to do with reality. You are not thinking about the users --you are not really trying to find real world solutions for the people who are actually going to implement the product. Why does this have to be an either or set-up? Why not add pathauto to the core and give it as an option for people to implement during installation? It is sloppy thinking to say you know better because you are a developer. Earth to geeks : Software development is never ending, it is never done. You will never be satisfied ---treat your skill as a disease not as a gift. You do not have to release 4.7 ---- you are JONESING for a new coding high. And in the process, undermining many a vendor, web admin and end user by pushing into obsolescence their just installed site. If you have to release 4.7, go ahead and do it. But make sure that it is as flexible and user centric as possible so that you can stop, stand back and think of what better ways to implement the product as opposed to just talk about code as art. For that, there is always bitforms gallery [ www.bitforms.com ] and software and net art lists sites like Rhizome [ www.rhizome.org ] and The Thing [www.thing.net ]. Best, liza, who's been on the software art scene for far too long, sabater
Why does this have to be an either or set-up? Why not add pathauto to the core and give it as an option for people to implement during installation? It is sloppy thinking to say you know better because you are a developer.
Liza, As someone who's a die-hard evangelist for pathauto, I'll be the first to say that it needs work before being unleashed on *every single Drupal site*. As others have noted, it gets unwieldy with large lists of nodes (say, 10,000) and it gets tremendously confused when your rules result in the same path for multiple pieces of content. There are other issues, too. They're certainly not insurmountable! But one of the things that keeps Drupal useful as a platform for developing web apps is the lean-and-mean highly-focused core. As others have noted, actual end-user installations will almost ALWAYS require additional contrib modules and tweaking. I think that incorporating the concept of pathauto into the core path.module is an awesome idea. Making sure it doesn't paint users into a corner is just as important, though. Does that make any sense? --Jeff
On Nov 23 2005, at 01:25, Jeff Eaton wrote:
I think that incorporating the concept of pathauto into the core path.module is an awesome idea. Making sure it doesn't paint users into a corner is just as important, though. Does that make any sense?
Totally. And again, I don't think it has to be an either/or issue. Make it so people can choose at the moment of installation whether they want to have their links blurbed or not. Which means, stop a minute and think about how Drupal can take the CivicSpace installer and make it even yummier. Again, sexy can be as simple as making it easy to have multiple small or middle sized options as opposed to just one efficient yet not quite satisfying big one. / liza
Look, someone did a really bad, and I mean, really HORRIDLY BAD call when they decided to take out the sessions setting options for the 4.6 release.
You broke so many rules about market strategy, usability and software development, I can't even fathom how you came to the conclusion this was a good idea. Then again, yes, I can fathom the logic just by the discussion we are having here.
That clueless person would have been me. (Make no mistake, I don't regret that change.)
And you did changes to the RSS system as well, and not for the good of the user but for the good of your geekatude.
I don't know what RSS changes you are talking about.
You think about the beauty of the code, the simplicity of your logic. That's nice and good. The problem is that it has nothing to do with reality. You are not thinking about the users --you are not really trying to find real world solutions for the people who are actually going to implement the product.
Please, either provide some constructive suggestions, learn how open source software development works, find a CMS that you like better, or pass the crack-pipe around so us idiotic geeks can share your unanimous insights on market strategy, usability, communication, software development and real world solutions. -- Dries Buytaert :: http://www.buytaert.net/
Liza Sabater wrote:
On Nov 21 2005, at 11:50, Chris Johnson wrote:
Liza seems to be saying "yes, Andre is the only one who thinks that way" but perhaps it was just sloppy use of English and she meant "yes, I agree with Andre."
Heh.
No, I did mean the first meaning.
Don't get me wrong, I love most of the time how software developers think. It's sexy, but just like a lot of sexy stuff out there, it has somewhat to do with reality :)
The way regular, non-software developers use Drupal seems to be very different from the way you guys conceive of it. I personally do not care about the url BUT the reality is that you will most likely get faster indexing of your sites by bots --and better stumble upon traffic-- if you have verbose links as opposed to those "node/ doohickey/numbers" system. It's not your fault or the users, it's just is. So having flexibility on how those links are created, right off the bat, is what Drupal ought to be striving for.
Look, someone did a really bad, and I mean, really HORRIDLY BAD call when they decided to take out the sessions setting options for the 4.6 release. It was in 4.5, my
That option was actually taken out long before. It might have been in 4.4 but I think it was already removed there, at least if you are referring to the horrible little "remember me" checkbox.
site never logged me out and it seemed that a lot of people found it useful as well. Not only did y'all take it out, but it is nowhere stated in your documentation that this was taken out. And not only did you take it out but, guess what, a lot of people have grumbled about this on the support list (or so it seems),
Yes, was great fun.
because it was not announced nor was there an option offered to deal with potential log-out problems. I had 5 people look at this problem on my site and one of them came across this story by diving into your support archives. And you did changes to the RSS system as well, and not for the good of the user but for the good of your geekatude.
You show us that you ain't no clue.
Rule #1 : If it aint broke, dont fix it.
Teh horrible little checkbox thing was broken, that is why it was removed.
You broke so many rules about market strategy, usability and software development, I can't even fathom how you came to the conclusion this was a good idea. Then again, yes, I can fathom the logic just by the discussion we are having here.
A discussion? You are biting the hand that codes your software. Very bad move.
You think about the beauty of the code, the simplicity of your logic. That's nice and good. The problem is that it has nothing to do with reality. You are not thinking about the users --you are not really trying to find real world solutions for the people who are actually going to implement the product.
Right. Why on earth should we? Why should we give a damn about any of your problems? They are your problems after all, not ours.
Why does this have to be an either or set-up? Why not add pathauto to the core and give it as an option for people to implement during installation?
Because we have many users that already whine about not being able to LOCK their tables and us evil developers using such a feature. because people insist on using hoisters that charge them 5 of whatever currency and the people still expect they can run kick-ass software with kick-ass features on their el-cheapo hosting.
It is sloppy thinking to say you know better because you are a developer. Earth to
No, it is just right. We know better because we simply know our software, the software it depends on, and so on. We are the Gods, you are the dust on our feet.
geeks : Software development is never ending, it is never done. You will never be satisfied ---treat your skill as a disease not as a gift. You do not have to release 4.7 ---- you are JONESING for a new coding high. And in the process, undermining many a vendor, web admin and end user by pushing into obsolescence their just installed site.
Again, why should we care?
If you have to release 4.7, go ahead and do it. But make sure that it is as flexible and user centric as possible so that you can stop, stand back and think of what better ways to implement the product as opposed to just talk about code as art. For that, there is always bitforms gallery [ www.bitforms.com ] and software and net art lists sites like Rhizome [ www.rhizome.org ] and The Thing [www.thing.net ].
You really, really have no clue. You should be a specimen at the no-clue museum.
Best, liza, who's been on the software art scene for far too long, sabater
Liza, I think we've had enough of you. Please close the door - from the outside.
No, it is just right. We know better because we simply know our software, the software it depends on, and so on. We are the Gods, you are the dust on our feet.
I'm not here to defend or flame Liza (though it seems that she deserves a little of both)... I'm just going to toss this out there: When developers start referring to themselves as Deities - they also start to believe that they are infallible - and they start to believe that they know all and can do no wrong. Such arrogance is the downfall of all empires. Be great - but also be humble. Biting the hand that codes your software may be a faux pas - but so is pissing on the community that gives you your raison detre. and finally
Why on earth should we? Why should we give a damn about any of your problems? They are your problems after all, not ours.
If you don't bother to even consider the comments or concerns of community members - i.e. joe average-end-user or jane super-user - you are no longer a software engineer or developer - your just a code monkey flinging meticulously polished elegant and efficient turds of code. andre (who happens to like the meticulously polished elegant efficient code - and appreciates every ounce of effort the authors put into the code - but can never lose sight of his clients needs - and if the code doesn't meet their needs - I will have no choice but to do some ugly hacks and workarounds that even if contributed to the community would never get past the gatekeeps - and perhaps rightly so) ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
andre wrote:
No, it is just right. We know better because we simply know our software, the software it depends on, and so on. We are the Gods, you are the dust on our feet.
I'm not here to defend or flame Liza (though it seems that she deserves a little of both)...
I'm just going to toss this out there:
When developers start referring to themselves as Deities - they also start to believe that they are infallible - and they start to believe that they know all and can do no wrong.
You don't think I was serious about that, do you? I avoid to use smileys, they take away the element of surprise.
Such arrogance is the downfall of all empires.
Be great - but also be humble.
Biting the hand that codes your software may be a faux pas - but so is pissing on the community that gives you your raison detre.
No, no, and no. The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it. The reason is to get stuff done for our own needs. You are free to use it, too. But that's it.
and finally
Why on earth should we? Why should we give a damn about any of your problems? They are your problems after all, not ours.
If you don't bother to even consider the comments or concerns of community members - i.e. joe average-end-user or jane super-user - you are no longer a software engineer or developer - your just a code monkey flinging meticulously polished elegant and efficient turds of code.
No, I am solving *my* problems. If those problems are somebody else's problems too, then that is fine with me. But I am not adopting problems I am not interested in. Not without a fee, anyway. Cheers, Gerhard
On Nov 23 2005, at 09:50, Gerhard Killesreiter wrote:
No, no, and no. The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it. The reason is to get stuff done for our own needs. You are free to use it, too. But that's it.
Gerard, This is shocking for me to read. Seriously. I neve intended to offend people with my lame jokes about geekatude but this comment is ... well ... wow. I've had my eye on Drupal since 2002. Back then I did not had a clue of what a blog was. All I wanted was something that would make my life easier publishing on the web. I liked what you had but held off because, as a power user of blogging software and not a developer, I needed something that was easier to deal with. b2 is what I really wanted but by then the software had been abandoned (it reappeared later as both WordPress and b2evolution). So I went the route of MovableType because of its support and vendor communities. I came back to Drupal for one reason : CivicSpace. What Zack et al have accomplished with that distribution is impressive. And as political bloggers like me grow their practices from personal op-ed diaries to activist communities, CivicSpace is, in my not so humble opinion, the best thing out there for the potential growth of networks of online political communities. From a strategic POV, CivicSpace/Drupal makes more sense to me than Scoop. But most activist community sites in the US are going the route of Scoop. It took just one person, who happens to be also the owner of the largest political community site in the US, to make the decision of Drupal vs. Scoop and he went the route of Scoop for 2 reasons : it's support and vendor communities. Do you see a pattern here? Scoop, MovableType and WordPress are gaining big chunks of market share (especially in publishing) in the US while Drupal/CivicSpace is on tentative ground due in part to the dichotomy between the development and the marketing of Drupal. I am the only blogger from the top 100 moving to CivicSpace at the moment. MediaGirl runs a Drupal site (not CivicSpace). Bob Brigham of Swing State Project (another top 100) started a site on CivicSpace but that's another short-term campaign site. In this case the campaign is www.scalito.org. He was converted to CivicSpace in part by me. Epluribus Media, a citizen journalism site that came out of DailyKos, has 2 sites running : one on Scoop for their research work and the other one on CivicSpace for their blogging. They were converted to CivicSpace in part by Lynn Siprelle. Yeah, a lot of you call blogs hype and all that; but the reality is that blogging is here to stay. If anything, you are poised to get more development resources with long-term political community sites than short-term campaigns because you'll have people who've had enough time to understand the product --even if they were not developers . So your disregard about community in creating a community and content platform is troubling. / liza
No, no, and no. The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it. The reason is to get stuff done for our own needs. You are free to use it, too. But that's it.
Gerard,
This is shocking for me to read. Seriously. I neve intended to offend people with my lame jokes about geekatude but this comment is ... well ... wow.
Don't be shocked - there is no overall agreement about what this project is or whom it is for. Gerhard has his opinions. I happen to disagree with him that "The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it." - but I get to have my own opinion.
But most activist community sites in the US are going the route of Scoop. It took just one person, who happens to be also the owner of the largest political community site in the US, to make the decision of Drupal vs. Scoop and he went the route of Scoop for 2 reasons : it's support and vendor communities.
This doesn't mean that Scoop is a better product, that it has better support or that there is a stronger vendor community. From what I could tell Kos went with Scoop because people in his social network thought it would be a good idea.
Do you see a pattern here?
well yes this is the description of a pattern - but I'm not sure where the data is coming from. We all have our perceptions of where thing are going. In my view Scoop is a minor player (in terms of market acceptance)
Scoop, MovableType and WordPress are gaining big chunks of market share (especially in publishing) in the US while Drupal/CivicSpace is on tentative ground due in part to the dichotomy between the development and the marketing of Drupal.
I'm not sure how you arrive at "Drupal/CivicSpace is on tentative ground"... MoveableType - Drupal is not - yet.
I am the only blogger from the top 100 moving to CivicSpace at the moment. MediaGirl runs a Drupal site (not CivicSpace). Bob Brigham of Swing State Project (another top 100) started a site on CivicSpace but that's another short-term campaign site. In this case the campaign is www.scalito.org. He was converted to CivicSpace in part by me. Epluribus Media, a citizen journalism site that came out of DailyKos, has 2 sites running : one on Scoop for their research work and the other one on CivicSpace for their blogging. They were converted to CivicSpace in part by Lynn Siprelle.
if the goal is to move Drupal into the top 100 blog sites then we should do that - in my view it would be pretty easy. That isn't the goal of this community (I don't think that is on many people's radar).
Yeah, a lot of you call blogs hype and all that; but the reality is that blogging is here to stay. If anything, you are poised to get more development resources with long-term political community sites than short-term campaigns because you'll have people who've had enough time to understand the product --even if they were not developers .
So your disregard about community in creating a community and content platform is troubling.
So I think that your point of view is interesting and worthwhile - but I'm not sure that I buy into all your assumptions and metrics.
/ liza
Liza Sabater wrote:
On Nov 23 2005, at 09:50, Gerhard Killesreiter wrote:
No, no, and no. The "community" (I hate that word) is not the reason d'etre for Drupal or the reason why anybody would develop for it. The reason is to get stuff done for our own needs. You are free to use it, too. But that's it.
This is shocking for me to read. Seriously. I neve intended to offend people with my lame jokes about geekatude but this comment is ... well ... wow.
Lisa, this shows me that you have never been involved with open source development before. Welcome in the kitchen...
I've had my eye on Drupal since 2002. Back then I did not had a clue of what a blog was. All I wanted was something that would make my life easier publishing on the web. I liked what you had but held off because, as a power user of blogging software and not a developer, I needed something that was easier to deal with. b2 is what I
That's completely ok. I am not one of the people who wants all people to use Drupal for all kind of use cases. I think that Drupal is simply too much if you look for single user blog. Use wordpress instead.
really wanted but by then the software had been abandoned (it reappeared later as both WordPress and b2evolution). So I went the route of MovableType because of its support and vendor communities.
And you paid for it (which is completely acceptable).
I came back to Drupal for one reason : CivicSpace.
What Zack et al have accomplished with that distribution is impressive. And as
True, but I'd have that spelled Neil et al. ;) (merely for the reason that I don't really know what Zack does and Neil sends patches)
political bloggers like me grow their practices from personal op-ed diaries to activist communities, CivicSpace is, in my not so humble opinion, the best thing out there for the potential growth of networks of online political communities. From a strategic POV, CivicSpace/Drupal makes more sense to me than Scoop.
I am rather surprized that you mention Scoop. It isn't a topic of debate on drupal.org unlike Mambo, Wordpress, ....
But most activist community sites in the US are going the route of Scoop. It took just one person, who happens to be also the owner of the largest political community site in the US, to make the decision of Drupal vs. Scoop and he went the route of Scoop for 2 reasons : it's support and vendor communities.
Do you see a pattern here?
You want to pay for using Drupal and getting paid support? This is not a problem.
Scoop, MovableType and WordPress are gaining big chunks of market share (especially in publishing) in the US while Drupal/CivicSpace is on tentative ground due in part to the dichotomy between the development and the marketing of Drupal.
I am not really interested in market share. I want people to use software that does what they need done. If MT fits the bill better than Drupal for a particular use case, then so be it.
I am the only blogger from the top 100 moving to CivicSpace at the moment. MediaGirl runs a Drupal site (not CivicSpace). Bob Brigham of Swing State Project (another top 100) started a site on CivicSpace but that's another short-term campaign site. In this case the campaign is www.scalito.org. He was converted to CivicSpace in part by me. Epluribus Media, a citizen journalism site that came out of DailyKos, has 2 sites running : one on Scoop for their research work and the other one on CivicSpace for their blogging. They were converted to CivicSpace in part by Lynn Siprelle.
This is all very nice, but is only helpfull if Drupal is better software for their use cases. (Of course I think it is)
Yeah, a lot of you call blogs hype and all that; but the reality is that blogging is here to stay.
I always cringe when blogging is mentioned in conjunction with Drupal. Drupal is not a blogging tool (not in the sense the LJ or MT are).
If anything, you are poised to get more development resources with long-term political community sites than short-term campaigns because you'll have people who've had enough time to understand the product --even if they were not developers .
You probably know that I am on contract with CivicSpace, atm. I therefore get a lot of insight into the needs of such community sites. I am not sure this is in all cases directly related to Drupal core development. They are not different than other clients with regard to this.
So your disregard about community in creating a community and content platform is troubling.
The problem I have with the term "community" is that it is used to often and often not very specific. Incidentally, my own use case of Drupal involves communities. But those communities are real-life and not on-the-web and the membership of those is thus clearly defined. Cheers, Gerhard
Gerard, On Nov 23 2005, at 04:55, Gerhard Killesreiter wrote:
You broke so many rules about market strategy, usability and software development, I can't even fathom how you came to the conclusion this was a good idea. Then again, yes, I can fathom the logic just by the discussion we are having here.
A discussion? You are biting the hand that codes your software. Very bad move.
No, I am not. I want to bring attention to what other people around the world are saying about you. And I am trying to do it in a way that starts a conversation that gives us all a positive outcome. I know you are the lead developers and I am grateful for your work. If I did not think it was worthy, I'd go find something else. What I am trying to get to here is that you have a world of improvements to make that do not necessarily involve re-coding Drupal --that is, if Drupal is a product and not a software development lab. Why is this important? If you are not in the business of creating a product but instead are just here as a software development lab, then instead of coming to Drupal for a CMS; vendors, users, and web developers might just have to stand back and say : OK, I am going to stick to the features in 4.6 and create a parallel support structure just for that release. So, in effect, people might have to make a decision as to look at each release as not just a code fork but a market development fork for the release as well. To you as a developer this does not make sense. You are always on the lookout for better code.That's normal; it means you're coder. But for people who are looking at Drupal as a product to build a business infrastructure, it may well be the only way to go. And that means, right now, that there is no business support infrastructure for people looking at Drupal AS A PRODUCT and not a software development lab. It means that people like me have to stand and think ... hmmm ... what can I do to create a support infrastructure that will work for the next 18 months; all the while creating an "upgrade bridge" for OUR (not Drupal's) next upgrade. Do you get where I am coming from? So, I need to be in here to understand your process as an outsider because Gerhard Killesreiter at this moment, does not seem to have the business objectivity to answer these questions. I mean, c'mon, you're releases are coming out every 4-6 months. That's insane for people in the real world. Whatever happened to the 12-18 months for new releases? There is so much that could be done just in UI in between releases that, honestly, why are you rushing to the next decimal? Again, the pertinent question : Is Drupal a product or a software development lab? <snip>
No, it is just right. We know better because we simply know our software, the software it depends on, and so on. We are the Gods, you are the dust on our feet.
Jokes are a great way of presenting our view of reality and this joke of yours is your truth. The question is, should it be Drupal's? Liza Sabater, Publisher www.culturekitchen.com
Liza Sabater wrote:
Again, the pertinent question : Is Drupal a product or a software development lab? Liza That's a very good question. Fortunately it is not very hard to answer.
Drupal is Open Source. Open Source is driven by coders who have an itch. They scratch the itch they have. They have no obligation to scratch yours or mine. Some even have the audacity to mention it openly! ;-) Drupal is not a product first. It is a process, a way of life, a living system and an experimental development lab. Drupal is also a product, but it is not a commercial product, so don't expect the same culture around it as you'll find around word for instance. We don't have paid supporters to take the abuse from frustrated customers and turn it into satisfying solutions. Also - even though Drupal people are quite focussed on usability issues, help and support - these tasks are not a "attractive" to most people in the community. That is the way it is. Don't expect anything else. The Drupal community has hitherto been very friendly and forthcoming when people had issues with the software. Drupal is now so bogged down by its own success, that the core developers cannot be expected to be as available as the next release is approaching fast. Development cycles: Even large professional systems (like MBS Axapta - the system I work with on a daily basis) have more than one "rhythm". Full releases are two years, smaller ones more frequent. (I'm not a programmer, I'm a communications guy and an Information Architect and I love Drupal and the community around it) Best Gunnar
On 23-Nov-05, at 9:35 AM, Liza Sabater wrote:
On Nov 23 2005, at 04:55, Gerhard Killesreiter wrote:
You broke so many rules about market strategy, usability and software development, I can't even fathom how you came to the conclusion this was a good idea. Then again, yes, I can fathom the logic just by the discussion we are having here.
A discussion? You are biting the hand that codes your software. Very bad move.
No, I am not. I want to bring attention to what other people around the world are saying about you. And I am trying to do it in a way that starts a conversation that gives us all a positive outcome.
This is prefaced with an acknowledgment that there are valid points from all parties (there are no "sides" here, just people talking). The use of attack language on both sides is troubling ("you" rather than "we")...we're all in this together, and can contribute different things. IMHO, this is not the right forum. These -- as much as you would like to think they are -- are not development issues (which this list is for), but rather community/marketing issues. The documentation list has a marketing sub-component, and at some point the consultants@drupal.org list will be up that will be more business and best practice oriented. I'm happy to discuss this further off-list.
To you as a developer this does not make sense. You are always on the lookout for better code.That's normal; it means you're coder. But for people who are looking at Drupal as a product to build a business infrastructure, it may well be the only way to go. And that means, right now, that there is no business support infrastructure for people looking at Drupal AS A PRODUCT and not a software development lab. It means that people like me have to stand and think ... hmmm ... what can I do to create a support infrastructure that will work for the next 18 months; all the while creating an "upgrade bridge" for OUR (not Drupal's) next upgrade.
Help build/fund the installer and updater, which should make things a lot easier for non-technical users. 4.6 is never abandoned, it just doesn't get new features. If your business roadmap includes a need for certain features, consider setting aside funding for these. I admit I am confused about the perceived need to upgrade existing sites? I used to routinely skip upgrades (e.g. 4.0 --> 4.2 --> 4.4).
Do you get where I am coming from? So, I need to be in here to understand your process as an outsider because Gerhard Killesreiter at this moment, does not seem to have the business objectivity to answer these questions. I mean, c'mon, you're releases are coming out every 4-6 months. That's insane for people in the real world. Whatever happened to the 12-18 months for new releases? There is so much that could be done just in UI in between releases that, honestly, why are you rushing to the next decimal?
Again, the pertinent question : Is Drupal a product or a software development lab?
Neither. It is most like Ruby on Rails -- a web application framework. The framework doesn't care about users...that is up to individual consultants, developers, and yes, businesses. If the economics are there to have business support structures arise...they will arise. That is exactly why distributions -- whether CivicSpace, DrupalED, or anything else -- make sense. Communities can form on pushing and supporting products, rather than a toolkit. Drupal has gotten MORE framework-like over time, and less like a "product". Hope that was a useful contribution. That's all from me on the subject on this list. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
I think people are confusing core with distribution. The node/id system is simple, effective, and the best way to have nodes with unique ids at the highest performance. Whatever aliasing system you use (path, pathauto, supermegahoochypath) should be optional. If by "part of core" people mean the core distribution and that means it's a disablable module that is well-maintained, great. If by "part of core" people mean it's the new standard for identifying all nodes, no way. Liza makes some good points, and we should be mature enough to recognize the points she makes and ignore her offensive style instead of lashing back, which accomplishes nothing. Yes, Drupal has a marketing problem. Yes, most of us don't care about that and feel that if she thinks Drupal has a marketing problem she should start marketing Drupal and get involved with decision making, and maybe roll her own easy-to-use distribution (maybe pathauto will even be on by default!). Or maybe she could fund implementation of session remembrance. She is also right that 4.7 is going to be a lot of work for a lot of people without a lot of tangible benefit and we should recognize that (I know I do). I don't have a problem with that if we are steadily working towards best practices in everything. 4.7 is an example of best practices with forms, since they are now (more) secure.
John VanDyk wrote:
I think people are confusing core with distribution.
People are confusing a lot of things.
The node/id system is simple, effective, and the best way to have nodes with unique ids at the highest performance.
Whatever aliasing system you use (path, pathauto, supermegahoochypath) should be optional. If by "part of core" people mean the core distribution and that means it's a disablable module that is well-maintained, great. If by "part of core" people mean it's the new standard for identifying all nodes, no way.
Liza makes some good points, and we should be mature enough to recognize the points she makes and ignore her offensive style instead of lashing back, which accomplishes nothing.
Heh, you have no idea; it gives a lot of pleasure and relieves tension to wield the clue bat. My blood pressure is at an all time low.
Yes, Drupal has a marketing problem.
Does it? Somebody recently did a google query and found 60000 Drupal sites. He probably missed half of them since he used an English search string.
Yes, most of us don't care about that and feel that if she thinks Drupal has a marketing problem she should start marketing Drupal and get involved with decision making, and maybe roll her own easy-to-use distribution (maybe pathauto will even be on by default!). Or maybe she could fund implementation of session remembrance.
In any case she should keep it off this list, since it is not development related.
She is also right that 4.7 is going to be a lot of work for a lot of people without a lot of tangible benefit and we should recognize that (I know I do). I don't have a problem with that if we are steadily working towards best practices in everything. 4.7 is an example of best practices with forms, since they are now (more) secure.
So what are you trying to say? I don't get it. Nobody forces people to upgrade the same moment that 4.7 is released. They can take their own time, set up a test site, and migrate once they are ready. We will be providing security patches for 4.6 until 4.8 will be available. So they probably have at the very least half a year from now. And if they don't want to upgrade at all, they can even do that. And if they don't want to do updates, they will need to get a nice hosting provider which runs their Drupal for them and makes updated modules available, etc. Plenty of possibilities. Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Nov 2005, at 4:56 PM, Gerhard Killesreiter wrote:
And if they don't want to do updates, they will need to get a nice hosting provider which runs their Drupal for them and makes updated modules available, etc.
I wonder if we know anyone that does that kind of thing ? </tongue in cheek> - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDhIV9gegMqdGlkasRAsnkAJ4nhWQD22LMBdksTfbJ5C0yXDr7eQCfToAZ zQOgupiGHsOA185QL3YEeRk= =c7lZ -----END PGP SIGNATURE-----
She is also right that 4.7 is going to be a lot of work for a lot of people without a lot of tangible benefit and we should recognize that (I know I do). I don't have a problem with that if we are steadily working towards best practices in everything. 4.7 is an example of best practices with forms, since they are now (more) secure.
So what are you trying to say? I don't get it.
I have lots of Drupal sites running. Many of these sites have special modules. These modules will have to be rewritten for 4.7 to do exactly the same thing they are already doing. This will take time. Time = money. Every time we break backwards compatibility there is a cost. I'm saying that I'm OK with that as long as it improves Drupal, but that the cost should be recognized as well, and as Drupal's popularity increases, so does the cost.
These modules will have to be rewritten for 4.7 to do exactly the same thing they are already doing. This will take time. Time = money.
if (benefits > costs) { upgrade_to_47(); } else { stick_with_46(); } Whether the benefits of upgrading to Drupal 4.7 outweight the costs of upgrading to Drupal 4.7, is something only you can determine: it's unique to your situation. For the exact same reason, people are still using WinNT or Win98.
Every time we break backwards compatibility there is a cost.
True, but at the same time we gain things too. Similarly, not breaking code often comes at a cost as well; it holds back improvements, makes code harder to maintain, makes it harder to customize Drupal, has performance implications, etc. Clearly, there is a tension between breaking backward compatibility and not breaking backward compatibility. Unfortunately, there is no "winner" because the costs can't be quantified. Not the absolute costs. Not the relative costs. I'm in the camp that, we are best of breaking backward compatibility when necessary; it buys us maintainability and flexibility, which, in turn, makes for a longer product lifecycle. -- Dries Buytaert :: http://www.buytaert.net/
On Wed, 2005-11-23 at 17:15 +0100, Dries Buytaert wrote:
These modules will have to be rewritten for 4.7 to do exactly the same thing they are already doing. This will take time. Time = money.
if (benefits > costs) { upgrade_to_47(); } else { stick_with_46(); }
Clearly, there is a tension between breaking backward compatibility and not breaking backward compatibility. Unfortunately, there is no "winner" because the costs can't be quantified. Not the absolute costs. Not the relative costs. I'm in the camp that, we are best of breaking backward compatibility when necessary; it buys us maintainability and flexibility, which, in turn, makes for a longer product lifecycle.
And more billable development hours if you play your cards right ;). I'm in the same camp. I was poking through some of the earlier versions of drupal... I think the changelogs indicated late 90's early 00's... I'm glad drupal isn't 100% backwards compatible.
Op woensdag 23 november 2005 17:15, schreef Dries Buytaert:
Clearly, there is a tension between breaking backward compatibility and not breaking backward compatibility. Unfortunately, there is no "winner" because the costs can't be quantified. Not the absolute costs. Not the relative costs. I'm in the camp that, we are best of breaking backward compatibility when necessary; it buys us maintainability and flexibility, which, in turn, makes for a longer product lifecycle.
Lets see this is as a test case. But let us measure the "costs" in amounts of developers leqving Drupal, or even sticking with 4.6 (and thus not upgrading their contribs, or thus not contributing back to bugs and so in 4.7). And let us hope that the amount of new developers that are attracted by the easier development will at least break us even. I think we cannot quatify these costs, but we can catch an overal feeling. Ber
developers leqving Drupal, or even sticking with 4.6 (and thus not upgrading their contribs
IMO this release is easier for newcomers and harder for those who already know Drupal. There is a lot to re-learn, the new node hooks/nodeapi ops, the form API (in Morbus speak: fapi :D). Regards NK
Op woensdag 23 november 2005 23:21, schreef Karoly Negyesi:
developers leqving Drupal, or even sticking with 4.6 (and thus not upgrading their contribs
IMO this release is easier for newcomers and harder for those who already know Drupal. There is a lot to re-learn, the new node hooks/nodeapi ops, the form API (in Morbus speak: fapi :D).
Yes, this is what I mean. If, netto, we have substantial more developers at the end of 4.7, we made the correct choice. I beleive we should count our success mostly in the "currency" Developers. I do not care about amount of users, per se, to me they are but a factor to get more developers. We should take the word "developer" with a grain of salt, though. Anyone contributing to the development of Drupal is a developer in this case. Ber
I think I want to be sure I understand this. On 11/24/05, Bèr Kessels <ber@webschuur.com> wrote:
If, netto, we have substantial more developers at the end of 4.7, we made the correct choice. I beleive we should count our success mostly in the "currency" Developers. I do not care about amount of users, per se, to me they are but a factor to get more developers. We should take the word "developer" with a grain of salt, though. Anyone contributing to the development of Drupal is a developer in this case.
By "users" you mean 'people that use web sites built using Drupal'? And by "developers" you mean 'people that build web sites using Drupal, + plus project contributors"? I hope? Because when I think of Drupal users I think of "people that build web sites using Drupal' and developers, to me, are project contributors.
Let me stress that this is my opinion. Op donderdag 24 november 2005 15:20, schreef Earl Dunovant:
I think I want to be sure I understand this.
On 11/24/05, Bèr Kessels <ber@webschuur.com> wrote:
If, netto, we have substantial more developers at the end of 4.7, we made the correct choice. I beleive we should count our success mostly in the "currency" Developers. I do not care about amount of users, per se, to me they are but a factor to get more developers. We should take the word "developer" with a grain of salt, though. Anyone contributing to the development of Drupal is a developer in this case.
By "users" you mean 'people that use web sites built using Drupal'? And by "developers" you mean 'people that build web sites using Drupal, + plus project contributors"?
No. I mean people that download drupal and use it for their website. A developer would be any of these users that actually contributes something back. I (and again, let me stress that letter *I*), am not really waiting for people filing feature requests on my contribs. Nor people filing bug reports for OddFlavouredHostingProvider. Those are their itches. My itches are to get stuff working here. Nor for those that ask support, because they cannot find docs for one of these contribs. I am waiting, however for people whom either contribute a patch, or write a nice howto or doc page on something. Or who actively help by handing me good ways to improve *my* experience of these contribs. I know. This is selfish. But I do this for myself, in the first place. I am not developing stuff for FooBar Inc. or Joe User. If they can reuse my work that is great. If they then contribute bak that is even better. But once they start costing me, my time, and my efforts (and sometimes even manage to flame me in that process.....) I can really do without them. They use "our" bandwith, "our" CPU cycles, demanding our time and give nothing back. Hence comes my statement that one should not calculate an OSS project based on numbers of users, but on amount of actively involved people.
I hope? Because when I think of Drupal users I think of "people that build web sites using Drupal' and developers, to me, are project contributors.
I undersatnd the attitude that "the only thing that matters are contributors", however I would argue that the more users you have, the more contributors you will have. It all gets back (IMHO) to how you define the project, what the goals and objectives are etc. Drupal is a very strong project and if nothing changed it would continue to be so I think. I believe that a lot of this conversation is because you have new people coming into the arena with their own ideas, aspirations and needs. Dan
Let me stress that this is my opinion.
Op donderdag 24 november 2005 15:20, schreef Earl Dunovant:
I think I want to be sure I understand this.
On 11/24/05, Bèr Kessels <ber@webschuur.com> wrote:
If, netto, we have substantial more developers at the end of 4.7, we made the correct choice. I beleive we should count our success mostly in the "currency" Developers. I do not care about amount of users, per se, to me they are but a factor to get more developers. We should take the word "developer" with a grain of salt, though. Anyone contributing to the development of Drupal is a developer in this case.
By "users" you mean 'people that use web sites built using Drupal'? And by "developers" you mean 'people that build web sites using Drupal, + plus project contributors"?
No. I mean people that download drupal and use it for their website.
A developer would be any of these users that actually contributes something back.
I (and again, let me stress that letter *I*), am not really waiting for people filing feature requests on my contribs. Nor people filing bug reports for OddFlavouredHostingProvider. Those are their itches. My itches are to get stuff working here. Nor for those that ask support, because they cannot find docs for one of these contribs.
I am waiting, however for people whom either contribute a patch, or write a nice howto or doc page on something. Or who actively help by handing me good ways to improve *my* experience of these contribs.
I know. This is selfish. But I do this for myself, in the first place. I am not developing stuff for FooBar Inc. or Joe User. If they can reuse my work that is great. If they then contribute bak that is even better.
But once they start costing me, my time, and my efforts (and sometimes even manage to flame me in that process.....) I can really do without them. They use "our" bandwith, "our" CPU cycles, demanding our time and give nothing back.
Hence comes my statement that one should not calculate an OSS project based on numbers of users, but on amount of actively involved people.
I hope? Because when I think of Drupal users I think of "people that build web sites using Drupal' and developers, to me, are project contributors.
Op donderdag 24 november 2005 19:46, schreef Dan Robinson:
I undersatnd the attitude that "the only thing that matters are contributors", however I would argue that the more users you have, the more contributors you will have.
I already mentioned that users are a route towards new developers, Not only because the more users you have the bigger the chances are there is a contributer inbetween, but also because a lot of users spend money on hiring developers for drupal. However, to the project itself, IMO the only thing that really counts, in the end, is the amount of active contributors. All the rest can be ignored.
I believe that a lot of this conversation is because you have new people coming into the arena with their own ideas, aspirations and needs.
Oh, buit this is a good thing, imo. It keeps drupal from rusting.
I'm totally not arguing with you btw :).
I undersatnd the attitude that "the only thing that matters are contributors", however I would argue that the more users you have, the more contributors you will have.
I already mentioned that users are a route towards new developers, Not only because the more users you have the bigger the chances are there is a contributer inbetween, but also because a lot of users spend money on hiring developers for drupal.
However, to the project itself, IMO the only thing that really counts, in the end, is the amount of active contributors. All the rest can be ignored.
isn't what you just said contradictory? What am I missing - Users [help create] new developers [and create] marketplace [which brings] new developers so how can you then turn around and say "...the only thing that really counts, in the end, is that amount of active contributors.." I'm just wondering :). Also I just had a thought (everybody cover your ears...) Is the project about the developers/contributors or is it about the code. I wonder...
I believe that a lot of this conversation is because you have new people coming into the arena with their own ideas, aspirations and needs.
Oh, buit this is a good thing, imo. It keeps drupal from rusting.
agreed :)
This is a very interesting issue, IMHO. Sorry for all those bored with this thread. Op donderdag 24 november 2005 20:55, schreef u:
I'm totally not arguing with you btw :).
No, I got that; I think we agree, but i think this is an interesting discussion.
I undersatnd the attitude that "the only thing that matters are contributors", however I would argue that the more users you have, the more contributors you will have. I already mentioned that users are a route towards new developers, Not only because the more users you have the bigger the chances are there is a contributer inbetween, but also because a lot of users spend money on hiring developers for drupal.
However, to the project itself, IMO the only thing that really counts, in the end, is the amount of active contributors. All the rest can be ignored.
isn't what you just said contradictory? What am I missing -
Users [help create] new developers [and create] marketplace [which brings] new developers
so how can you then turn around and say "...the only thing that really counts, in the end, is that amount of active contributors.."
I'm just wondering :).
No this does not contradict: If one runs a company, one can easily say: in the end its all about the balance, the money. Having clients is cool: But clients that only cost money, or even clients that do not bring any money, are nice, yet do not help. in the end, A company can then say "The profit is all that matters, in the very end. Whether that is genrated by no clients at all, only one client or thousands of clients does not matter". In the same line we can say: The only thing that we can calculate our value off, is the amount of contributors, not the amount of users". Hell, we can have a million of users, yet only two developers. In that case we have a serious problem :)
Also I just had a thought (everybody cover your ears...) Is the project about the developers/contributors or is it about the code. I wonder...
I believe that a lot of this conversation is because you have new people coming into the arena with their own ideas, aspirations and needs.
Oh, buit this is a good thing, imo. It keeps drupal from rusting.
agreed :)
I'd throw in a different metric, just for kicks. An open source project, since it doesn't have a money or income issue (at least not directly), is not financially driven. It is driven by need, vis, solving a problem. It is a tool. No more, no less. Therefore, the success of a tool is the number of problems (either unique problems or number of problem cases) that the tool solves. A hammer solves pretty much just one problem, but it's an extremely common problem and it solves it really well, so it's a successful tool. Drupal can be used to solve a large number of different problems, and it's being used in several thousand unique problems. It's not actually the number of people using the tool that determines its success, it's the number of problems solved with it; by whom doesn't matter. One person solving 1 million problems or a million people solving one problem each are both 1 million problems solved, and so its success is 1 million. On Friday 25 November 2005 02:56 am, Bèr Kessels wrote:
This is a very interesting issue, IMHO. Sorry for all those bored with this thread.
Op donderdag 24 november 2005 20:55, schreef u:
I'm totally not arguing with you btw :).
No, I got that; I think we agree, but i think this is an interesting discussion.
I undersatnd the attitude that "the only thing that matters are contributors", however I would argue that the more users you have, the more contributors you will have.
I already mentioned that users are a route towards new developers, Not only because the more users you have the bigger the chances are there is a contributer inbetween, but also because a lot of users spend money on hiring developers for drupal.
However, to the project itself, IMO the only thing that really counts, in the end, is the amount of active contributors. All the rest can be ignored.
isn't what you just said contradictory? What am I missing -
Users [help create] new developers [and create] marketplace [which brings] new developers
so how can you then turn around and say "...the only thing that really counts, in the end, is that amount of active contributors.."
I'm just wondering :).
No this does not contradict: If one runs a company, one can easily say: in the end its all about the balance, the money. Having clients is cool: But clients that only cost money, or even clients that do not bring any money, are nice, yet do not help. in the end, A company can then say "The profit is all that matters, in the very end. Whether that is genrated by no clients at all, only one client or thousands of clients does not matter".
In the same line we can say: The only thing that we can calculate our value off, is the amount of contributors, not the amount of users".
Hell, we can have a million of users, yet only two developers. In that case we have a serious problem :)
Also I just had a thought (everybody cover your ears...) Is the project about the developers/contributors or is it about the code. I wonder...
I believe that a lot of this conversation is because you have new people coming into the arena with their own ideas, aspirations and needs.
Oh, buit this is a good thing, imo. It keeps drupal from rusting.
agreed :)
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 25 Nov 2005, at 10:16, Larry Garfield wrote:
I'd throw in a different metric, just for kicks. An open source project, since it doesn't have a money or income issue (at least not directly), is not financially driven. It is driven by need, vis, solving a problem. It is a tool. No more, no less.
For a metric to be useful, we must be able to quantify it. We can quantify the number of users, the number of downloads, the number of developers, the number of projects, the number of forum topics, the number of CVS commits, etc. We can't (easily) quantify the number of problems Drupal solved. -- Dries Buytaert :: http://www.buytaert.net/
This is a very interesting issue, IMHO. Sorry for all those bored with this thread.
oh c'mon - we must be close to setting a record :)
Op donderdag 24 november 2005 20:55, schreef u:
I'm totally not arguing with you btw :).
No, I got that; I think we agree, but i think this is an interesting discussion.
yes. I think so as well :)
I undersatnd the attitude that "the only thing that matters are contributors", however I would argue that the more users you have, the more contributors you will have.
I already mentioned that users are a route towards new developers, Not only because the more users you have the bigger the chances are there is a contributer inbetween, but also because a lot of users spend money on hiring developers for drupal.
However, to the project itself, IMO the only thing that really counts, in the end, is the amount of active contributors. All the rest can be ignored.
isn't what you just said contradictory? What am I missing -
Users [help create] new developers [and create] marketplace [which brings] new developers
so how can you then turn around and say "...the only thing that really counts, in the end, is that amount of active contributors.."
I'm just wondering :).
No this does not contradict: If one runs a company, one can easily say: in the end its all about the balance, the money.
yeah - you can say it is all about the money - but if it is for you then that is sad. There's a process - and you better enjoy that process, otherwise you won't be very happy.
Having clients is cool: But clients that only cost money, or even clients that do not bring any money, are nice, yet do not help. in the end, A company can then say "The profit is all that matters, in the very end. Whether that is genrated by no clients at all, only one client or thousands of clients does not matter".
In the same line we can say: The only thing that we can calculate our value off, is the amount of contributors, not the amount of users".
I think this is way too simplistic and reductionist. I agree that just having lots of users isn't it either (if I thought so I would go off and use mambo or whatever it is called now :) ). But to say that users don't matter is silly (for me).
Hell, we can have a million of users, yet only two developers. In that case we have a serious problem :)
it seems unlikely that that could ever happen. Also there are hundreds of drupal developers (perhaps 1000s) who don't contribute code back - we should try to fix that. One thing that I'm starting to conclude from this conversation is that the motivations and interests between different participants is really different. I wonder if there are not clusters. Very interesting discussion - I need to think about this for a while.
Also I just had a thought (everybody cover your ears...) Is the project about the developers/contributors or is it about the code. I wonder...
I believe that a lot of this conversation is because you have new people coming into the arena with their own ideas, aspirations and needs.
Oh, buit this is a good thing, imo. It keeps drupal from rusting.
agreed :)
Dan Robinson wrote:
it seems unlikely that that could ever happen. Also there are hundreds of drupal developers (perhaps 1000s) who don't contribute code back - we
Mabye we can take the opportunity to fix the term "Drupal developer". In my book a Drupal developer is somebody who contributes patches to Drupal core on a more or less regular basis. Assuming that definition we maybe have 20 developers. People who develop their own modules and put them in Drupal's contrib CVS are module developers. Likewise for people contributing themes. The other people you mention are just some users. Yes, users. They use Drupal in one of the many ways it can be used. Cheers, Gerhard
On 23 Nov 2005, at 14:11, Bèr Kessels wrote:
Op woensdag 23 november 2005 17:15, schreef Dries Buytaert:
Clearly, there is a tension between breaking backward compatibility and not breaking backward compatibility. Unfortunately, there is no "winner" because the costs can't be quantified. Not the absolute costs. Not the relative costs. I'm in the camp that, we are best of breaking backward compatibility when necessary; it buys us maintainability and flexibility, which, in turn, makes for a longer product lifecycle.
Lets see this is as a test case. But let us measure the "costs" in amounts of developers leqving Drupal, or even sticking with 4.6 (and thus not upgrading their contribs, or thus not contributing back to bugs and so in 4.7). And let us hope that the amount of new developers that are attracted by the easier development will at least break us even.
Ber, very nicely stated. I think that's an entirely reasonable criteria. Unfortunately, the 4.7 cycle has placed me in the drop-out camp. Somewhere around August or September, I realized that each CVS pull would cost me several hours of development time (downloading from CVS; merging into my local Perforce repository; figuring out what APIs had changed out from under me -- I have quite a bit of custom code; and dealing with many white-screens-of-death). Many of those multi-hour sessions were prompted by the false hope that what had been broken by the previous CVS pull would be fixed this time around. After my "day job" (I hate that term, but can't think of anything better) and family life, I have maybe 10 to 20 hours per week to spend on my web sites. Far too much of that time was going into this debugging effort, so I've now backtracked to 4.6.x plus a few specific upgrades that are useful to me (notably freetagging). No value judgement here, just a data point. I'd love to be able to contribute bug fixes and some of the custom work I'm doing, but the cost of keeping up has become too high. I'll probably wait until a month or two after 4.7 is released before considering an upgrade again. -Eric
On 23 Nov 2005, at 15:20, John VanDyk wrote:
Liza makes some good points, and we should be mature enough to recognize the points she makes and ignore her offensive style instead of lashing back, which accomplishes nothing. Yes, Drupal has a marketing problem. Yes, most of us don't care about that and feel that if she thinks Drupal has a marketing problem she should start marketing Drupal and get involved with decision making, and maybe roll her own easy-to-use distribution (maybe pathauto will even be on by default!). Or maybe she could fund implementation of session remembrance.
I agree that Liza made some good points, as well as bad points. Liza has high expectations of Drupal (a good thing), and it shows. Fortunately, we're well aware of most points. If she did her research, she would have known, and she would not have to offend the many contributors that donate time, money and resources trying to advance Drupal. Either way, let's focus on constructive action points as how to overcome some of Liza's concerns, and see if someone steps forward to take on the work it takes. Let's define a number of manageable tasks that could be implemented ...
She is also right that 4.7 is going to be a lot of work for a lot of people without a lot of tangible benefit and we should recognize that (I know I do). I don't have a problem with that if we are steadily working towards best practices in everything. 4.7 is an example of best practices with forms, since they are now (more) secure.
Whether 4.7 will have tangible benefit depends on your situation. Fact is that 4.7 comes with many improvements that are visible to the user; better templating, free-tagging, contact forms, better search, better syndication, and usability improvements all over the map. At the same time, there are many improvements that are less visible to the user, but that are essential to advance Drupal's technical capabilities; the new forms API and the improved node revisions being prominent examples. Changes like this will help advance the many contributed modules to become simpler and/or more feature-rich. For example, the forms API will help flexinode/CCK, the improved node revisions will help the wiki module(s). It is what it takes, and unfortunately, it can be disruptive. As both you point, the challenge is to get Drupal 4.7 out, to update the contributed projects, and to simplify the migration process for those who want to upgrade to Drupal 4.7. -- Dries Buytaert :: http://www.buytaert.net/
Hi Liza, Wow! This should be a "must read" for developers. No joking. I won't say I fully agree with all the points, but it's really worth reading. Actually I'd say your opinions are equally unbalanced, on the side of the site admins who only want to keep their site up to date with a minimum pain. But we need some 'balance' here anyway - I mean in this devs list. :-) Thanks, Jose Liza Sabater wrote:
On Nov 21 2005, at 11:50, Chris Johnson wrote:
Liza seems to be saying "yes, Andre is the only one who thinks that way" but perhaps it was just sloppy use of English and she meant "yes, I agree with Andre."
Heh.
No, I did mean the first meaning.
Don't get me wrong, I love most of the time how software developers think. It's sexy, but just like a lot of sexy stuff out there, it has somewhat to do with reality :)
The way regular, non-software developers use Drupal seems to be very different from the way you guys conceive of it. I personally do not care about the url BUT the reality is that you will most likely get faster indexing of your sites by bots --and better stumble upon traffic-- if you have verbose links as opposed to those "node/ doohickey/numbers" system. It's not your fault or the users, it's just is. So having flexibility on how those links are created, right off the bat, is what Drupal ought to be striving for.
Look, someone did a really bad, and I mean, really HORRIDLY BAD call when they decided to take out the sessions setting options for the 4.6 release. It was in 4.5, my site never logged me out and it seemed that a lot of people found it useful as well. Not only did y'all take it out, but it is nowhere stated in your documentation that this was taken out. And not only did you take it out but, guess what, a lot of people have grumbled about this on the support list (or so it seems), because it was not announced nor was there an option offered to deal with potential log-out problems. I had 5 people look at this problem on my site and one of them came across this story by diving into your support archives. And you did changes to the RSS system as well, and not for the good of the user but for the good of your geekatude.
Rule #1 : If it aint broke, dont fix it.
You broke so many rules about market strategy, usability and software development, I can't even fathom how you came to the conclusion this was a good idea. Then again, yes, I can fathom the logic just by the discussion we are having here.
You think about the beauty of the code, the simplicity of your logic. That's nice and good. The problem is that it has nothing to do with reality. You are not thinking about the users --you are not really trying to find real world solutions for the people who are actually going to implement the product.
Why does this have to be an either or set-up? Why not add pathauto to the core and give it as an option for people to implement during installation? It is sloppy thinking to say you know better because you are a developer. Earth to geeks : Software development is never ending, it is never done. You will never be satisfied ---treat your skill as a disease not as a gift. You do not have to release 4.7 ---- you are JONESING for a new coding high. And in the process, undermining many a vendor, web admin and end user by pushing into obsolescence their just installed site.
If you have to release 4.7, go ahead and do it. But make sure that it is as flexible and user centric as possible so that you can stop, stand back and think of what better ways to implement the product as opposed to just talk about code as art. For that, there is always bitforms gallery [ www.bitforms.com ] and software and net art lists sites like Rhizome [ www.rhizome.org ] and The Thing [www.thing.net ].
Best, liza, who's been on the software art scene for far too long, sabater
Andre Molnar wrote:
p.s. Am I the only one that sees beauty in the simplicity of example.com/node/13 meaning the 13th node of content on a site - and node/1000345 being the 1,000,345th node on a site... and am I the only
one that thinks 1 million aliases might be a bit silly to generate automatically?
As a unique ID, that works smashingly. As a recognizable URL, it works quite badly. Obviously, there are some cases where it is unecessary. I DO think, though, that path.module is next to useless on any site that gets updated unless you combine it with pathauto.module. --Jeff
Andre Molnar wrote:
Adrian Rossouw wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 20 Nov 2005, at 11:21 PM, Andre Molnar wrote:
Path auto is the epitome of a contributed module. It serves a purpose that many people may find useful, but is NOT REQUIRED and does not serve a CORE purpose. User-friendliness is a core purpose imo.
I believe being able to create human readable URL's automatically is something we should build upon wherever possible. I also think we should turn pathauto into more of an API, so modules / nodes / pages can expose properties to be used in url's.
I also believe we should never ever show a node id to an end user.
I hate software that tries to think for me. (If another word processing program dares to, by default, capitalize something that I didn't capitalize to begin with - or another IDE, by default, adds so much as a line break to my code - or if any software suggests another file name for me when I go to save - so help me god I'm going to... ... fume because there's nothing else I can do). How can we as developers presume to KNOW how the end user wants to see their URL's?
And if the user / developer wants to change the default 'human readable' URL, they will still have to turn to path-alias or another path tool to do so AND/OR hack some code to do it (API or no API). What have we gained?
I agree. My experience shows that newbies are comfortable dealing with node ids. They are easier to remember and understand. I don't know about pathauto, but if it can't handle transliteration of unicode correctly, it's not worth it. The only way today to do this is to use the translit[1] extension AFAIK. [1] http://pecl.php.net/translit -- Bertrand Mansion http://www.mamasam.com - creative internet solutions http://golgote.freeflux.net - my blog
How about a stack? (Read from bottom to top) Drupal Verticals (Education, Blogging, CivicSpace yada yada) Drupal Experimental - All the other stuff (this is sandbox) Drupal Community Contribs - Lots of other stuff (new / part of current contribs) Drupal Base Modules - relatively generic, popular, highly desireable, maintained stuff (new / part of current contribs) Drupal Core - totally generic everyone needs them stuff (this is core) If I was drawing a picture it would be a bunch of stacked boxes and L shapes showing a somewhat more sophisticated "stacking". Don't go all wacky on the naming (just put it here for a conversation starter). And who are the "customers" Accidental Webmaster Webmasters ISVs / Consultants / VARs Developers Each of the above is it's own defined group with specific needs/desires. IMHO Drupal currently does an excellent job with Developers (and pretty well (but not as well) with the others). Simply making more of a distinction between the modules would go a long way in helping these users. Dan
Adrian Rossouw wrote:
I agree, but I believe that pathauto like functionality should be part of our default install, and we should emphasise it. It's one of our more powerful features, and the improvements in usabilty and browsability are amazing. Plus google loves you much much much more.
Okay - people have lost their minds (sorry don't mean to single you out here Adrian - especially considering your comments later on in this thread - and all the work that you do, but this comment just floored me enough to end months of silence).
What floored me is the irony that the topic should come up in a thread about creating a leaner core that can support multiple distributions.
Path auto is the epitome of a contributed module. It serves a purpose that many people may find useful, but is NOT REQUIRED and does not serve a CORE purpose.
(Core module = module absolutely required to make the software/development environment work.)
I've more or less given up trying to define what Drupal is. Its a lot of things to a lot of different people. (I'm finally coming around to thinking of it as two distinct things: 1) a rapid software development platform 2) a Drupal Branded CMS that uses has the rapid software development platform at its core). But I can define what Civicspace is - I can define what DrupalArt is - I can define what Drupal Blog is - I can define what DrupalEd is etc. And I know that Drupal is at the CORE of all of them.
So I'm in full agreement with Jose's idea of 'one core to serve them all'. If something doesn't 'serve them all' it has no place in core.
Take this idea to its logical conclusion and Forum.module should be dropped from core.
"HERESY!!!," the masses rise up and shout. "That's where drupal all began. BURN THE HERETIC."
Fine - light your torches - but when your done and Drupal 5.0 comes out with a full installer that starts with a lean core and adds only whatever users need and/or want - you'll realize that your already on the same page.
andre
p.s. As for multiple contributed modules that do more or less the same thing. If people don't want to work together it doesn't matter. Natural selection will take place. Competition is good. The module that adapts the quickest to the needs of the community will become the defacto standard - until a new competitor comes along.
Why did someone write Drupal when there was another forum tool available at the time? Why do people improve Drupal when they could be working on phpNuke ;-)? The multiple contrib module issue is a non-issue.
Hi Charlie, I meant to discuss more on the 'core' concept than about which modules... But anyway I'd just propose some module that creates simple node types on the fly -only with a new name- I've heard of, but I haven't seen yet :-) -- Then we can drop story, page, blog.... Karoly Negyesi wrote:
The problem is: currently we are pretending Drupal -core- to be too many things at the same time, mostly that great developer platform (1), but also an out of the box ready to use community portal (2) or kind of that. And the consequence is we are handling too many issues when fixing bugs for 'Drupal core' that are too specific of some more 'user level, site specific' modules.
Without a doubt, blog or aggregator is not the same level of functionality as node or taxonomy not to mention the required modules.
Here is a proposed core set:
block comment filter help locale (because this lets you change strings so its always useful) menu node path search story system taxonomy throttle upload user watchdog
(hope I have not missed any required ones :) )
Regards
NK
On Sat, 19 Nov 2005 22:02:22 +0100, Jose A. Reyero <jareyero@wanadoo.es> wrote:
Hi Charlie,
I meant to discuss more on the 'core' concept than about which modules... But anyway I'd just propose some module that creates simple node types on the fly -only with a new name- I've heard of, but I haven't seen yet :-) -- Then we can drop story, page, blog....
mmmm I had a simplenodes concept module, i think it's in the issue queue, for more complex stuff, we have cck.
Hi, I'm new on the list. I've subscribed to this list because I'd like to contribute Drupal if I can get enough knowledge and time. 2005-11-19, szo keltezéssel 19.52-kor Karoly Negyesi ezt írta:
Here is a proposed core set:
block comment
I think, i18n functions should be handled by the core. The problem of a multilanguage site is too global to handle by an outside module. Just look to the ecommerce module (locations, zones for taxes, etc.) or node translations (there's no "good" association between the translation and the original node) or menu.module. You have to patch the core if you'd like to get the existing i18n to work. On the whole, I'd like to see i18n in the core. Bests, -- Aries
Hi Fehér, Fehér János wrote:
I think, i18n functions should be handled by the core. The problem of a multilanguage site is too global to handle by an outside module.
I agree. I am the module maintainer.
Just look to the ecommerce module (locations, zones for taxes, etc.) or node translations (there's no "good" association between the translation and the original node) or menu.module. You have to patch the core if you'd like to get the existing i18n to work.
The next version -4.7- won't need patches anymore -unless we want to go for some new features, of course...
On the whole, I'd like to see i18n in the core.
Well, that one, let's take it easy. The current i18n.module has too many hacks and workarounds to avoid core patches, and would need to be reworked to be a core module. But we are making progress :-) Quite slowly though :-( Hope to see you around helping and supporting the idea of 'multilingual Drupal' -whatever form -module, core...- it takes at the end :-) Cheers, Jose
Bests,
2005-11-22, k keltezéssel 13.47-kor Jose A. Reyero ezt írta:
Well, that one, let's take it easy. The current i18n.module has too many hacks and workarounds to avoid core patches, and would need to be reworked to be a core module. But we are making progress :-) Quite slowly though :-(
Hope to see you around helping and supporting the idea of 'multilingual Drupal' -whatever form -module, core...- it takes at the end :-)
I'd like to help, that's why I ask you to write down what do you think about the future of the i18n. It would helpful to split the tasks into parts. Bests, -- Aries
Op dinsdag 22 november 2005 14:59, schreef Fehér János:
2005-11-22, k keltezéssel 13.47-kor Jose A. Reyero ezt írta:
Well, that one, let's take it easy. The current i18n.module has too many hacks and workarounds to avoid core patches, and would need to be reworked to be a core module. But we are making progress :-) Quite slowly though :-(
Hope to see you around helping and supporting the idea of 'multilingual Drupal' -whatever form -module, core...- it takes at the end :-)
I'd like to help, that's why I ask you to write down what do you think about the future of the i18n. It would helpful to split the tasks into parts. Agreed.
We all recognise Drupal clearly lacks any support in this region. But if you look around, you will see all the ingredients are there. It is "just" a matter of getting some cooks that can prepare those ingredients and make a nice dish from it. We, that is the people who want this supprt most, seem to all lack time and or skills to get this finished. Drupal itsself is very much developer oriented, while the biggest professional installations are all situated in the US. That makes the need for proper i18n rather small. US corporations dont need it, developers dont need it, they all talk english in the developer places. so, i think above all, we need something done. We need a renewed i18n for 4.7 and a group of active developers around that. José, what do you think about makeing i18n maintained by a group, rather then only you? I am not saying you cannot do the job, don't get me wrong, I am just saying we need more hands to get this on rails and get a bunch of good solutions out the door for 4.7, Ber
so, i think above all, we need something done. We need a renewed i18n for 4.7 and a group of active developers around that. José, what do you think about makeing i18n maintained by a group, rather then only you? I am not saying you cannot do the job, don't get me wrong, I am just saying we need more hands to get this on rails and get a bunch of good solutions out the door for 4.7,
jose just stated that he would love some help. what kind of a solution is it to propose a committee? i think you proposed the same thing with theme system. IMO, the way to "get this on rails" is to make tickets for things that should change, and then work to close those tickets. skip the committee.
Op woensdag 23 november 2005 14:23, schreef Moshe Weitzman:
what kind of a solution is it to propose a committee? i think you proposed the same thing with theme system. IMO, the way to "get this on rails" is to make tickets for things that should change, and then work to close those tickets. skip the committee.
heh, Is it still not clear that I am the hater of any comittee. I used to run around with anarchy signs all over me ;) A group is not a committee. A group is a bunch of people that have a common denominator (or some other word). What I propose is to FIRST think what we all need. I spoke to Jose and to Gerhard, who both want some internationalization. But all three of us need different things. So we could go out and make three i18n-s. But much better would it be if we grouped around what all three of us need, and on top of that build our own little house. Ber
Bèr Kessels wrote:
heh, Is it still not clear that I am the hater of any comittee. I used to run around with anarchy signs all over me ;)
Same here. Every time I read "committee", I just think of people discussing all day but producing nothing at all...
What I propose is to FIRST think what we all need. I spoke to Jose and to Gerhard, who both want some internationalization. But all three of us need different things. So we could go out and make three i18n-s. But much better would it be if we grouped around what all three of us need, and on top of that build our own little house.
Yes, I've already been doing some work about Drupal + i18n, and think Gerhard has been doing the same... Hope we can share the results soon.. And I remember from the DrupalCon that you had some very interesting ideas about it. No doubt we should group together and get something done. And hope we won't end up producing some i19n, i20n modules -we are running out of available names in the contrib repository... ;-)
Ber
Op donderdag 24 november 2005 02:59, schreef Jose A. Reyero:
And I remember from the DrupalCon that you had some very interesting ideas about it.
Next week I start a project where I will use flexinode / form API for this, So any field can be duplicated for each language. What I wat to do too, is pull out the langauge switcher, and make that a separate module. Ber
Bèr Kessels wrote:
Op donderdag 24 november 2005 02:59, schreef Jose A. Reyero:
And I remember from the DrupalCon that you had some very interesting ideas about it.
Next week I start a project where I will use flexinode / form API for this, So any field can be duplicated for each language.
What I wat to do too, is pull out the langauge switcher, and make that a separate module.
Great, well have another one then :( What I was thinking was: pulling out the translation from i18n and make it a separate module, then have a lightweight i18n that would be mostly a language switcher :-) But I intended to do it for 4.7... Are you developing for 4.6 or 4.7 ?
Ber
Op donderdag 24 november 2005 10:55, schreef Jose A. Reyero:
What I was thinking was: pulling out the translation from i18n and make it a separate module, then have a lightweight i18n that would be mostly a language switcher
Sorry for the misunderstanding, we mean the same! And yes, this will be for HEAD,
On 11/20/05, Karoly Negyesi <karoly@negyesi.net> wrote:
Here is a proposed core set:
block comment filter help locale (because this lets you change strings so its always useful) menu node path search story system taxonomy throttle upload user watchdog
This is great: all those other modules SHOULD be moved out of core. But what concerns me is that they don't just get pulled out of core, and dumped straight into the spaghetti pit that is contrib ATM. We have to set up the 'endorsed modules' system first, so that these extra modules (e.g. forum, blog, aggregator, book) have a home to go to, rather than risk them getting 'lost in contrib'. These modules are currently (despite being too domain-specific for core) well-maintained and constantly improved, and this is because they're in core. We have to ensure that when they leave core, they're still in a place where this high-maintenance requirement continues. Jaza.
Op 22-nov-2005, om 13:57 heeft Jeremy Epstein het volgende geschreven: > On 11/20/05, Karoly Negyesi <karoly@negyesi.net> wrote: >> Here is a proposed core set: >> >> block >> comment >> filter >> help >> locale (because this lets you change strings so its always useful) >> menu >> node >> path >> search >> story >> system >> taxonomy >> throttle >> upload >> user >> watchdog > > This is great: all those other modules SHOULD be moved out of core. > But what concerns me is that they don't just get pulled out of core, > and dumped straight into the spaghetti pit that is contrib ATM. We > have to set up the 'endorsed modules' system first, so that these > extra modules (e.g. forum, blog, aggregator, book) have a home to go > to, rather than risk them getting 'lost in contrib'. These modules are > currently (despite being too domain-specific for core) well-maintained > and constantly improved, and this is because they're in core. We have > to ensure that when they leave core, they're still in a place where > this high-maintenance requirement continues. Well, the fact is that when a module doesn't get updated/improved the usage of the module is probably questionable.. Also the list above does still point to a certain direction of sites. I would vote for a light-weight core with even less modules and become a broader base for even more kind of websites, like: - block; - comment; - filter; - locale; - menu; - node; - path; - search; - story; - system; - taxonomy; - user; - watchdog. you see that help and throttle are moved from the list. Help because it points to newbies. Advanced users don't need it IMO, but I'm not very sure of this decision. Maybe it's better to display help by default, for everybody who's new. the throttle.module is only interesting and usable by high-traffic sites like kerneltrap.org and/or drupal.org-a-like sites. IMO it's too much for core, because there are lot's of people who use drupal for their own personal site and small business sites. the throttle.module is a little bit of an overkill for sites like that. Just some of my thoughts about this topic... --- Stefan Nagtegaal Drupal-Devel@iStyledThis.nl Drupal Development Mailinglist
On Tue, 22 Nov 2005 14:28:20 +0100 Stefan <drupal-devel@istyledthis.nl> wrote:
the throttle.module is only interesting and usable by high-traffic sites like kerneltrap.org and/or drupal.org-a-like sites. IMO it's too much for core, because there are lot's of people who use drupal for their own personal site and small business sites. the throttle.module is a little bit of an overkill for sites like that.
The throttle is useful to sites that have limited resources and usually are not that busy. It is actually less useful to consistently high-traffic sites, as by necessity they will already have the required infrastructure to survive high loads. The throttle works well for a website that's on a shared host with limited CPU and bandwidth, that usually only gets a handful of visitors, and then is suddenly Slashdotted. Of course, it will only help in that case if it has been enabled and properly configured. Cheers, -Jeremy
the throttle.module is only interesting and usable by high-traffic sites like kerneltrap.org and/or drupal.org-a-like sites. IMO it's too much for core, because there are lot's of people who use drupal for their own personal site and small business sites. the throttle.module is a little bit of an overkill for sites like that.
The throttle is useful to sites that have limited resources and usually are not that busy. It is actually less useful to consistently high-traffic sites, as by necessity they will already have the required infrastructure to survive high loads.
The throttle works well for a website that's on a shared host with limited CPU and bandwidth, that usually only gets a handful of visitors, and then is suddenly Slashdotted. Of course, it will only help in that case if it has been enabled and properly configured.
This is exactly the kind of information that would be useful to people. A description of what the module does, who it is for and an endorsement of it's quality. I wonder if we could start a book about this somewhere.
Cheers, -Jeremy
On Nov 23, 2005, at 9:01 AM, Dan Robinson wrote:
This is exactly the kind of information that would be useful to people. A description of what the module does, who it is for and an endorsement of it's quality. I wonder if we could start a book about this somewhere.
In Drupal 4.7 the administration help for throttle has been improved. It is sourced from here: http://drupal.org/handbook/ modules/throttle At the end of the help there is a link back to the page above. I have just added a child page called "When to use the throttle module". http://drupal.org/node/38661 Thanks to Jeremy and Dan for pointing this out. Cheers, Kieran
This is exactly the kind of information that would be useful to people.
A description of what the module does, who it is for and an endorsement
of it's quality. I wonder if we could start a book about this somewhere.
In Drupal 4.7 the administration help for throttle has been improved. It is sourced from here: http://drupal.org/handbook/modules/throttle
At the end of the help there is a link back to the page above. I have just added a child page called "When to use the throttle module". http://drupal.org/node/38661
right - and now we need (IMHO) a section of the website that will contextualize all these modules, tell me why I should care, and assure me that they are well supported and engineered.
Thanks to Jeremy and Dan for pointing this out.
Cheers, Kieran
On Nov 22 2005, at 08:28, Stefan wrote:
Advanced users don't need it IMO, but I'm not very sure of this decision. Maybe it's better to display help by default, for everybody who's new.
Sigh. Perfect example of what I was referring to in my previous email. / liza
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 8:31 PM, Jose A. Reyero wrote:
Well, I was writing this as a reply to a reply to the previous 'Encouraging collaboration' thread, but it's grown too big, so sorry, but I want to open a new thread.
A "great developer platform" is how I see Drupal, and I'm sure most of the developers too. But the thing is: we need some focus, some targets to agree on.
The install system makes provisions for this. You can create virtual packages, which have no actual modules / code of their own except for depending on other packages and having some configuration and possibly an installation wizard. When I said that the forms api is a key component of the install system, I wasn't joking. The new form api (only in 4.8 though. the 4.7 forms api is only phase one) will allow us to record macros, (ie: record all the forms you fill in), and create install profiles programmatically. It will also be possible to auto-create configuration wizards from these recorded macros, as wizards are just macros that have configurable values. I have a feeling we might even be able to clear up some of our menu mess.
Just as an example -and I have nothing against forum module: At some point, we are duplicating the taxonomy interface to handle a forum specific vocabulary. Then, this causes some bug -like this one, again just an example: http://drupal.org/node/24274 -, and then we have a *core bug*, module specific, but as it is a core module, this one has the same importance -in the bug tracking system- as any other critical bug -like a basic API not working properly. I would like to see the relationship API take over forum, taxonomy and book. So we have one system instead of all these disparate implementations of the same thing.
The same with the aggregator module which implements it's own node system, and taxonomy. The same with the project module which implements it's own comment system and taxonomy system. Whenever we need to implement something like this, it means our core system isn't flexible enough. And you have it wrong. The Drupal mantra is 'we should write an API for that'
But, anyway, that's an old idea. Just look at Linux.... Could you install 'Linux' --properly understood as the core OS- and pretend you have a nice OS ready to play with your computer?
I'd love to see core only be a handful of modules, but I really don't see it being an option before the install system is finished. Once 4.7 is out, I'm going to be putting together the DEP's for the rest of the install system, so we can discuss them (I actually have started writing my first DEP, it's just kind of hard since I don't have a format to follow, I am just playing it all by ear.) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf3mogegMqdGlkasRAs2UAJwNIEJenhnSL/mlEZlVdJ0WiD9VlACeNjj2 8PGqFYN8FF3OJIJzywWwT0A= =C3Xd -----END PGP SIGNATURE-----
Adrian Rossouw wrote:
The install system makes provisions for this.
You can create virtual packages, which have no actual modules / code of their own except for depending on other packages and having some configuration and possibly an installation wizard.
That's great!
When I said that the forms api is a key component of the install system, I wasn't joking.
The new form api (only in 4.8 though. the 4.7 forms api is only phase one) will allow us to record macros, (ie: record all the forms you fill in), and create install profiles programmatically. It will also be possible to auto-create configuration wizards from these recorded macros, as wizards are just macros that have configurable values.
You're scaring me a little bit ;-)
I have a feeling we might even be able to clear up some of our menu mess.
Just as an example -and I have nothing against forum module: At some point, we are duplicating the taxonomy interface to handle a forum specific vocabulary. Then, this causes some bug -like this one, again just an example: http://drupal.org/node/24274 -, and then we have a *core bug*, module specific, but as it is a core module, this one has the same importance -in the bug tracking system- as any other critical bug -like a basic API not working properly.
I would like to see the relationship API take over forum, taxonomy and book. So we have one system instead of all these disparate implementations of the same thing.
The same with the aggregator module which implements it's own node system, and taxonomy.
The same with the project module which implements it's own comment system and taxonomy system.
Whenever we need to implement something like this, it means our core system isn't flexible enough.
Well, I think our core system is flexible enough -because all that implementations don't need to patch the basic taxonomy system. Only that our core system 'is not user friendly enough' but it shouldn't have to be that anyway. It's the whole thing of 'Flexibility/options' vs 'usability for end users'
And you have it wrong.
The Drupal mantra is 'we should write an API for that'
Ok, we should write an API for having one smaller core and may distributions :-)
But, anyway, that's an old idea. Just look at Linux.... Could you install 'Linux' --properly understood as the core OS- and pretend you have a nice OS ready to play with your computer?
I'd love to see core only be a handful of modules, but I really don't see it being an option before the install system is finished. Once 4.7 is out, I'm going to be putting together the DEP's for the rest of the install system, so we can discuss them (I actually have started writing my first DEP, it's just kind of hard since I don't have a format to follow, I am just playing it all by ear.)
Well, me too. I want to see Drupal 4.7 out. I din't mean changing anything now, but start thinking about it before it grows more and more. What worries me is that, at the end, we may have that install system with a lot of profiles in core too, so it will grow bigger after all :-( I have some DEP in mind too, but I'll wait to see your DEP first. Btw, did you know that 'DEP' is Spanish for 'RIP', --Anyway I'm not superstitious and see a good future por DEPs ;-)
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
I see two separate issues here, actually. 1) Is Drupal a developer platform, a CMS, or both? I see no reason why it can't be both, personally. I also don't like the "Core and derivative systems" model. That will very likely result in "The Debian Problem", vis, the mainline system takes so long for anything to happen that you get fragmented derived distributions that are "mostly compatible" and also have added administrative overhead to keep them in sync. (I say this as a Debian Sid user. <g>) That's not a good thing. As a developer platform, it should encourage developers to build drop-in modules that can make it do whatever they want. That's what we do now (although some parts could be done better, which is the point of most discussion on this list <g>). Easily-interchangeable modules ALSO allows for a good user-CMS, because then the user can mix and match modules without having to worry about code. If the module isn't at that point, then the developer's job is not done. (And yes, I am speaking as a web developer.) 2) There's too many modules in core. Hey, I won't disagree with you there. :-) I've no use for most of the modules in core by default. At the same time, though, contrib is, as others have pointed out, not always reliable. There's overlap, modules are unmaintained, there's no vetting of a module or a developer before code gets in or gets flagged ready for a given release, etc. So how do I know WHICH method of image handling to use? (To date I've used inline and upload rather than image, because I've not figured image out. I'm sure there's a usability lesson in there somewhere.) My recommendation would be to have another "level" of modules, "endorsed" (or something less stupid sounding). First, strip the core shipped modules down to a minimum: the required modules, throttle, taxonomy, path, menu, upload, comment, image, page (the one node type), and possibly xml-rpc. (The exact list is subject to debate, of course.) That creates a core system that is lean, mean, but still functional for a basic bunch-of-pages site. Then, create an online "Download and install from archive" function, as others have said is slowly in the works, that lists only "endorsed" modules. forum, blog, email-this-page (or one of the dozen versions of it), story, many of the taxonomy_ modules, etc. A module only gets into the "endorsed" archive by meeting a certain level of stability, up-to-date-ness, having an active maintainer (which could be "the Drupal core team" like many are now), being sufficiently generally useful that more than one or two sites would need it, etc. They would not necessarily have to meet the same schedule as core, however. That way, core's stability is easier to maintain since there's less code, which also reduces the workload for big changes like the forms API. (Speaking of which, great job guys!!) It also encourages more modular, no-I-can't-take-that-hacky-shortcut design for the endorsed modules. It could also allow a larger selection of easily-available modules (categorized?), which in turn would, hopefully, reduce the amount of duplication that goes on because people simply don't know a module is there. (See also: email-this-page, tellafriend, etc.) A new version of core would require only a fraction of endorsed to be fully rock solid before it's released, though, say 1/3 or 1/2. The rest can be updated in the few weeks after launch. The "contrib" archive would remain the "someone thought this might be useful" dumping ground, and endorsed modules would start there before being brought up to the major leagues, but would not get any special billing the way endorsed modules would. Endorsed modules would be addressed by the docs team, but the big mass of contrib would not. This way, we have a lot more flexibility and modularity of the development process, improve the user experience for Joe User, don't alienate Peter Power user (this is the most important group!), and still allow Dan Developer free reign in contrib. OK, enough of me talking. :-) Any thoughts? On Saturday 19 November 2005 12:31 pm, Jose A. Reyero wrote:
Well, I was writing this as a reply to a reply to the previous 'Encouraging collaboration' thread, but it's grown too big, so sorry, but I want to open a new thread.
A "great developer platform" is how I see Drupal, and I'm sure most of the developers too. But the thing is: we need some focus, some targets to agree on.
The problem is: currently we are pretending Drupal -core- to be too many things at the same time, mostly that great developer platform (1), but also an out of the box ready to use community portal (2) or kind of that. And the consequence is we are handling too many issues when fixing bugs for 'Drupal core' that are too specific of some more 'user level, site specific' modules.
The main point is *core shouldn't need to be an out of the box nice site* that anyone can use, and we need to jump in the *one core, many distributions* idea for that. And that need to be an out of the box nice site is actually consuming far more effort than what could be a proper CMS core.
IMHO we are wasting efforts in some higher level modules, that should be more focused to get what is properly the core system working right in the first place. And I'm not making any judgement about which modules should be in core and which ones not. I mean,, ok to have a few nice modules in core, but when a module grows too much, because people wants all that nice features, and them to be easy to set up, we can a) move it out of 'core' or b) provide a basic one in core that can be extended by a contrib module.
Just as an example -and I have nothing against forum module: At some point, we are duplicating the taxonomy interface to handle a forum specific vocabulary. Then, this causes some bug -like this one, again just an example: http://drupal.org/node/24274 -, and then we have a *core bug*, module specific, but as it is a core module, this one has the same importance -in the bug tracking system- as any other critical bug -like a basic API not working properly.
Notice that on one side we have a very big module in core to handle forums, but on the other side we don't have an small one for what could be a badly needed feature for other modules to build upon: a basic image node module. -again just an example, but I'm not talking about forum vs image at all.
And as a side effect... How many modules you need to patch for what could be a small 'core patch' -if core was smaller- before your patch can be even considered because you can say at least 'it applys to HEAD' ?? And how many modules you need to re-patch again because of a minimum detail has changed in the main core patch during the follow up on the issue tracker?
So I want to insist on the idea of "many distributions to serve different sites, one core to serve them all" --nice 'mantra', isn't it? ;-)
But, anyway, that's an old idea. Just look at Linux.... Could you install 'Linux' --properly understood as the core OS- and pretend you have a nice OS ready to play with your computer?
Cheers,
Jose
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 19 Nov 2005, at 9:29 PM, Larry Garfield wrote:
My recommendation would be to have another "level" of modules, "endorsed" (or something less stupid sounding). First, strip the core shipped modules down to a minimum: the required modules, throttle, taxonomy, path, menu, upload, comment, image, page (the one node type), and possibly xml-rpc. (The exact list is subject to debate, of course.) That creates a core system that is lean, mean, but still functional for a basic bunch-of-pages site. This is one of the things I've wanted to do forever.
I would like to see separate repositories too, with stricter security review rules and a group of commiters, with their own assigned modules/tasks. Essentially so that we can implement a code signing system that is required before we allow modules to be downloaded to their machines via the install system, and only allow them to get other modules which haven't matured enough yet, if they physically edit a very big warning laden file. The same file would have an option to disable all traces of internet downloading from the system, to allow for closed systems. And i believe the default node module included, should be content.module, or more pointedly. CCK. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDf4LcgegMqdGlkasRAoh7AJ4iwpgFPgsp1vCeO5ORz8MQaBgn2ACeMIE+ UO12dMRU4YLLkJRfn6UPwUI= =YC0p -----END PGP SIGNATURE-----
Like this? - copy & paste from another email I've just sent What I'd like to have: - core: minimum cms engine with few basic modules - standard modules: a few more than the ones that are currently in core, but these must be the ones maintanined by core developers with 'core quality' - contributed modules: all the rest (and same for themes) Adrian Rossouw wrote:
On 19 Nov 2005, at 9:29 PM, Larry Garfield wrote:
My recommendation would be to have another "level" of modules, "endorsed" (or something less stupid sounding). First, strip the core shipped modules down to a minimum: the required modules, throttle, taxonomy, path, menu, upload, comment, image, page (the one node type), and possibly xml-rpc. (The exact list is subject to debate, of course.) That creates a core system that is lean, mean, but still functional for a basic bunch-of-pages site.
This is one of the things I've wanted to do forever.
I would like to see separate repositories too, with stricter security review rules and a group of commiters, with their own assigned modules/tasks. Essentially so that we can implement a code signing system that is required before we allow modules to be downloaded to their machines via the install system, and only allow them to get other modules which haven't matured enough yet, if they physically edit a very big warning laden file.
The same file would have an option to disable all traces of internet downloading from the system, to allow for closed systems.
And i believe the default node module included, should be content.module, or more pointedly. CCK.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
participants (32)
-
Adrian Rossouw -
andre -
Andre Molnar -
andrew morton -
Bertrand Mansion -
Boris Mann -
Bèr Kessels -
Chris Johnson -
Dan Robinson -
Dan Robinson -
Darrel O'Pry -
Dries Buytaert -
Earl Dunovant -
Eric Scouten -
Fehér János -
Gerhard Killesreiter -
Gunnar Langemark -
Jeff Eaton -
Jeremy Andrews -
Jeremy Epstein -
John VanDyk -
Jose A. Reyero -
Karoly Negyesi -
Kieran Lal -
Larry Garfield -
Liza Sabater -
Moshe Weitzman -
Neil Drumm -
Robert Douglass -
Stefan -
Vernon Mauery -
vlado