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

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)

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

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.

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

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.

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?

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));

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

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.

http://drupal.org/node/31716

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

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.

-----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-----

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

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.

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

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

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.

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

...

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

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

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

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

...

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.

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.

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

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.

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.

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 :)

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

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 :)

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

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:

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

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

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

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

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.

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

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

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.

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

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

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

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

-----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-----