May 2006 - Development - lists.drupal.org

DrupalCON Europe
by Dries Buytaert 20 Jul '06

20 Jul '06

Hello, as you might have read, we started planning this year's DrupalCON Europe. We're currently looking for a venue, and would like to know what the 'ideal setup' looks like in terms of meeting rooms and presentation rooms. Please share you ideas at http:// groups.drupal.org/node/363#comment-1371. Your input is required to move forward. -- Dries Buytaert :: http://www.buytaert.net/

2 1

Extend database abstraction layer, to include table creation.
by Adrian Rossouw 09 Jul '06

09 Jul '06

http://drupal.org/node/63049 Now that we have .install files for modules, I believe it is time we extended our database abstraction layer. I recommend we create the following extra functions : 1. db_create_table($tablename, $columns); // columns is an associative array with the 'name' => 'type' 3. db_drop_table($tablename); 3. db_create_index($tablename, $columns); // columns is an array of column names, or just a single column. 4. db_drop_index($tablename, $columns); 5. db_add_column($tablename, $column, $type); // PGSQL already has a similar function, but it isn't in both systems. 6. db_drop_column($tablename, $column); The installer that is coming in, will be converting the database.*sql files into a system.install file, and with these functions, we can collapse ALL THREE SCHEMA FILES, into a single, much simpler file. This will also _drastically_ simplify updates, and it will give us consistent usage of types across the database. Certain things will still need to happen only on postgres (like create function calls for instance), but this DRASTICALLY decreases the amount of work we have to do to support multiple db types. At the moment, there are no create table statements that can be changed in core itself (until we have a system.install) , however, contrib modules can already be ported to use these functions, which would mean that we have (preliminary) postgres support across the board on all contrib modules. These functions should possibly keep track of what tables / columns / indexes have already been created, that would allow us to check (in a cross db way) what tables are available, and maintaining this information could possibly be useful in the future, such as not creating tables which have already been created. Additionally, each of these functions can be used to trigger a process for entering additional database credentials, in the case that the specific database user is not allowed to create tables and the like. This also helps make the patch for the installer a lot simpler, so if you want to help out with the installer, this would be a good thing to get involved with =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

31 110

private message module maintainership
by Anguo 05 Jun '06

05 Jun '06

Hello, Please see: http://drupal.org/node/64756 http://drupal.org/project/privatemsg I mailed the maintainer yesterday, but didn't receive a reply yet. Can anyone commit patches? Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple. http://www.gnosis-usa.com/ Revolutionary Psychology, White Tantrism, Dream Yoga... http://www.masquilier.org/ Condorcet, Approval alternative, better voting methods.

6 7

hook_depend()
by Doq Doques 03 Jun '06

03 Jun '06

Hi. What about implementing hook_depend(). I mean module that depends on some module (e.g. taxonomy) must define function modulename_depend() { return array('taxonomy'); } Then if user has no taxonomy module turned on - he/she will be asked to do so or not. If not - he/she will be told that modulename can't be installed. Also when user disables taxonomy module then he/she will be told that modulename depends on taxonomy module and so modulename will be also turned off.

9 13

RE: [infrastructure] Re: [development] Drupal 4.5 unsupported
by Steven Peck 01 Jun '06

01 Jun '06

> -----Original Message----- > From: development-bounces(a)drupal.org > [mailto:development-bounces@drupal.org] On Behalf Of Larry Garfield > Sent: Tuesday, May 30, 2006 10:48 AM > To: development(a)drupal.org > Subject: Re: [infrastructure] Re: [development] Drupal 4.5 unsupported > > On Tue, May 30, 2006 8:59 am, Khalid B said: > > On 5/30/06, blogdiva(a)culturekitchen.com > <blogdiva(a)culturekitchen.com> > > wrote: > >> That's an awesome question. I'd like to hear from > developers and the > >> people in the marketing team. The question is at the core of what I > >> feel Drupal is overlooking at the moment --code freezes. > > > > Code freezes do happen. Once we have a release, its API > does not change > > (may be a tiny bit occasionally, but not normally). > > > > What we do not freeze is APIs between releases. How can we > move forward > > from 4.7 to 6.6 with the API remaining the same? Where would the new > > stuff go? Are you advocating we keep APIs forever? > > > > Read my comment here on where the energy should be focussed > (migration > > tools, > > transitional releases, and compatibility layers). > > > > http://baheyeldin.com/node/617 > > Honestly, I think part of the issue with the "stable API" > question is that > Drupal uses version numbers differently from many projects. > The de facto > standard for version numbers for most projects is > Major.Minor.Bug / x.y.z. > > Z increases only fix bugs. > Y increases add features, but don't break backward > compatibility with 3rd > party code. > X increases, all bets are off. > > Witness, for instance, KDE, which has evolved and improved > dramatically in > the 3.y.z cycle, but code for 3.0.0 still (generally) works > in 3.5.1. For > the upcoming 4.0, howver, there are no "sacred cows" and > everything will > need to be updated. > > For Drupal, Y increases, all bets are off. We technically > don't have Y > releases, just Z and X, but we use both of the first two > numbers for the X > releases. That throws a lot of people off. It actually > surprised me a > great deal, although fortunately it didn't affect my plans > significantly. > > Whatever else we do, we should probably make that clearer > right up front. > It's not inherently a bad development model, just an > unconventional one > that needs to be made clearer. > > --Larry Garfield > How much more clear can I make this? http://drupal.org/handbook/version-info The alias is recent but it has been at the top level of the handbook now for about a year. Should we link it in the Project download page for Drupal? There are other projects that use different from KDE versioning release scheme's as well. Drupal's been consistent for the 3 years I've used it with it's versioning information and method. The versioning scheme has not changed at all. -sp

12 19

GPL policy: request for clarification
by Nedjo Rogers 01 Jun '06

01 Jun '06

The GPL appears to allow us to combine GPL and "compatible" code in a single GPL-licensed package. Can we include such code in drupal.org CVS? This is a pressing issue because there is considerable interest in using external GPL-compatible but non-GPL Javascript libraries (Prototype, jQuery), at least in contrib and possibly as candidates for core. Our CVS policy states "All code must be licensed under GNU/GPL" (contributions README.txt). The practice has been to interpret this as meaning that open source libraries with "MIT" or similar licenses may not be included in Drupal CVS. However, the Free Software Project has designated a number of licenses, including the "MIT" license, as "compatible" with the GPL, because they impose no restrictions that conflict with the GPL, see http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses. The GPL FAQ specifically states, http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean, that the GPL permits you to "combine code released under the other [compatible] license with code released under the GNU GPL in one larger program" privided that "such a combination ... is released under the GNU GPL". In other words, apparently, we can GPL the combination of GPL code and code with compatible licenses. So, it appears, we should be free to include "MIT" and other compatible-licensed code in our CVS and releases, provided we make it clear we are thus GPL-ing the combination. So, can we go ahead and put such combinations in CVS? Can we consider/propose them for core?

9 11

Drupal 4.5 unsupported
by Gerhard Killesreiter 31 May '06

31 May '06

Hi there! As of the last security release Drupal 4.5 is de facto unsupported. Contributed modules and themes are already no longer repackaged (don't know who changed that and when). I plan to remove the existing tarballs from files/projects so that they are no longer for download. Please voice your objections soon (and you better have very good reasons ;). Cheers, Gerhard

24 67

Improving drupal.js
by Nedjo Rogers 31 May '06

31 May '06

There's a lot of interest among the AJAX/Javascript group at http://groups.drupal.org/ajax-developers in putting some energy into improving the good Javascript beginnings we made in 4.7. Ideas include: introducing a Drupal namespace, refining some of our implementations, improving event handling, registering behaviors, isolating effects so they're accessible to effects libraries. There's interest as well in the potential of adopting one of the leading js development libraries (jQuery http://jquery.com/, Prototype http://prototype.conio.net/, etc.) as a development base. To this end, we're considering a drupal.js Drupal Enhancement Proposal, http://groups.drupal.org/node/603, and have started a working group at http://groups.drupal.org/drupal-js. timcn has begun to sketch in a proposed approach at http://cvs.drupal.org/viewcvs/drupal/contributions/modules/drupal.js/. I also posted a note to the jQuery mailing list about the possibility of jQuery being available under GPL or LGPL and got an encouraging response from jQuery author John Resig, see the thread "Would you consider making jQuery available under the GPL?" at http://jquery.com/discuss/2006-May/, in particular http://jquery.com/discuss/2006-May/001414/. If you'd like to contribute, please wade in with your comments and suggestions on the draft DEP, http://groups.drupal.org/node/603, and join the drupal-js group. Cheers, Nedjo

1 0

social network module
by Albert Wong 30 May '06

30 May '06

Greetings - I don't generally post here, but I read your comment re: social networking and I didn't want it to fall through the cracks.. . so I just wanted to give you a little bit of (hopefully helpful) guidance, regarding which direction to take, in case you're looking for some. On dev / your 5.26.06 posting / it seemed as if you were trying to decide whether to go for developing either... (1) "social networking" capabilities, a la orkut -- for drupal end users -- (2) or network analysis -- for drupal admins. Personally, my vote is for polishing up the social network capabilies of drupal for end users, a la orkut. [In fact, (1) might be a prerequisite for a successful deployment of (2). Reasoning: without adequate SN capabilities, there might be little network infrastructure to analyze.] :-) Anyhow, that's my current interest and bias and in case you've elect to go that route, I've done some investigating of what drupal already has on offer, so could hopefully give you a bit of a head start. There's definitely stuff you can build on, although there's also quite a ways to go. The principal social networking tool available in Drupal, imho, currently, is Drupal's "buddylist.module" which is supposed to be the rough equivalent of the common "friends" function you find on all the popular SN sites, orkut, myspace, etc. The module is well written and well documented. So, I would consider building off of it. However, this module has two significant drawbacks, (1) First, under its current cvs setup, *buddy relations are not symmetrical*. That is, if A is buddy of B, it does not imply that B is buddy of A. That is, buddylist treats friendship relationships as *directional*, rather than *mutual*. This creates some confusing scenarios -- for example -- under the current setup, you can have the following situation: "Jack is buddies with Jill, but Jack is not buddies of Jill, where as Jill is not buddies with Jack, but Jill is buddies of Jack" [Did you get that? ;-)] Although there might be some very unusual special cases where a unidirectional friend relationship might be useful, this is clearly, generally, not the common semantic case. (2) Second, currently, *buddy relationships may be unilaterally determined*. That is, A can unilaterally decide to declare that he is buddies with B, regardless of B's consent. That is, for example: "Quasimodo, the crazy stalker, can decide *on his own* that he's buddies with Esmerelda, even though Esmerelda has placed a restraining order on Quasimodo." ;-) Again, this unilateral capability is not standard in the common usage of buddy relationships as a social networking tool - and for good reason, I believe. Generally, buddy relationships are mutually and *consensually* determined. There are other more superficial issues regarding the polishing of buddylist, but these two issues strike at the core of it, and should be tackled first, imho. A solution to these two issues above has been posted as a patch here http://drupal.org/node/11892 -- it is patch that I wrote -- with help from RobRoy -- and functions without a hitch on my site, www.ithou.org . This patch replaces the "asymmetric" / "non-consensual" framework with one that is "symmetric" and "consensual". It is still awaiting review. I imagine that you could assist in that polishing and review process and as part of your SoC contribution, you could help move Drupal and buddylist into a more solid social networking platform. Should this be of interest to you as part of your SoC project, please do not hesitate to contact me. Regards, Albert albert [at] ithou.org

3 2

RE: [infrastructure] Re: [development] Drupal 4.5 unsupported
by Boerland, Bert 30 May '06

30 May '06

-----Original Message----- From: development-bounces(a)drupal.org > I reread Jonathans posts twice, becuase this problem really interests me (I > studied operational engineering: Maintaining and upgrading large technical > facilities such as powerplants) I work in a huge datacenter where we manage k's of hosts for customers, so this interest me as well. As a general rule of thumb, we have the following policy. We upgrade: 1) if the /customer/ wants it and hence pays for it (new functionality / external resons) 2) if /operations/ wants it because it is cheaper to maintain a box (operational costs /internal reasons) 3) if /customer/operations/ want it due to securtity risks (preventing imago/repair costs) (note: 3 includes lifecycle management aka EOL as is the case with 4.5 right now) These are imho the only valid reasons to upgrade, oss or proprietary code. The fact that you dont have any license costs for oss doesnt change this, neither the fact that bazaar style coding gives you faster updates with more functionality. These are just parameters within these rules. Anyone is free to upgrade or not. The only thing that we have to do is to state what the criteria are for supporting older versions. And if you think you need support for older versions, anyone is free to start coding for 4.1 or buy support. I wouldnt call it smart though or futureproof.

1 0