Yes, us programmers can patiently explain a lot of things... ...but we'll see what the reality of the situation really is... Victor Kane http://awebfactory.com.ar http://projectflowandtracker.com "Let the capitalists pay for the crisis, not the working people" -- sign held in recent Buenos Aires demonstration On Sun, Jan 3, 2010 at 6:59 PM, Domenic Santangelo <domenics@gmail.com>wrote:

On 01/03/2010 03:33 PM, Ad wrote:

Hello,

To my opinion, the imminent release of the 7 core might better be delayed.

Hi, Ad,

For what it's worth, I've had more than one non-programmer friend offer the same suggestion. I'm sure others on the list have had the same experience. Nothing really more to add (Susan had some useful links in her response to you). :)

-D

On 3-Jan-10, at 4:47 PM, Susan Stewart wrote:

Ad,

Someone suggests this every time a new version of Drupal comes out -- always someone who, like yourself, is not a programmer and has no idea what such a thing entails. Get to know Drupal and its code a little better, and read http://drupal.org/node/65922 which explains why we don't cripple Drupal in the name of backwards compatibility, or worse, create some sort of kludgy compatibility layer to hold it down.

If a module has sufficient interest, it will be upgraded quickly to the next version of Drupal. Anyone can do it with an investment of time and programming skills, or of dollars. You can visit http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx to see a list of contrib modules that have promised to have a D7 compatible release on the day D7 is released.

I know that for non-programmers and those not familiar with Drupal, this all seems strange, but that first link I gave you is a great explanation of why it is part of the core Drupal philosophy.

Susan gave good resources here. I think it's a good goal to want to make 6 => 7 transitions easier on people. I think backwards-compatibility layers though are the wrong way to do it, not to mention impossible in most cases. The /right/ way to do it is to work on tools that make porting code between versions a much easier process. These tools are all consolidated in the Coder module: http://drupal.org/project/coder. There's a video at http://www.lullabot.com/videocast/porting-drupal-modules which shows converting a 5.x module to 6.x in about 15 minutes using Coder module and some basic copy/paste/modify PHP skills. Coder module works by having rules defined for each API change and raising warnings when it encounters old code. The 7.x version of Coder even comes with a new Coder Upgrade module (called Deadwood in 6.x), which will attempt to make the changes for you. Anyone who has the itch of making the 6.x => 7.x transition smoother should be hunkering down in the Coder module queue to write up some of the changes at http://drupal.org/update/modules/6/7 into rules that can then be applied en masse by everyone. Even if you don't consider yourself a "real" programmer, but you know enough to be dangerous, you could help with this task. It's a great way to get familiar with the changes you'll need to know in a few months, well ahead of time, and it helps make the transition to the new version easier for everyone. -Angie

On 01/03/2010 03:33 PM, Ad wrote:

...

Hello,

To my opinion, the imminent release of the 7 core might better be delayed.

Untill today, many mods for 5 and even 4, are not available for the 6 version.

And there are several mods that are neccesary on some websites, so in some cases one better doesn't migrate to 6 (or even not from 5 in fewer cases).

Do I propose waiting untill maybe all the mods are available for 6? No; that would not change anything to the fact, that it will take many years before almost all interesting mods are programmed for core 7.

What I propose is a bridge, cloud, integration of TWO cores; the 6 and 7 core: Two installations (might be on another server too).

Waste of time that better can be used programming core 7 mods...?

Maybe, but that bridge_cloud could serve also for 7 to the future 8, bridging and clouding the same Drupal versions, Mediawiki and many other programs.

Especially when its written like: 1) a very broad multifunctional adapter, 2) with additional the 6 to 7 bridge 3) and many other specific bridges to make for other programs.

I'm not a programmer except for a blue monday and not familiar with internal details of how Drupal works. So there probably are many hughe problems to resolve to get something like this done.

But: 1) a General Bridge-Cloud-Adapter for core 7? 2) then a 6_to_7_Bridge working with GBCA? 3) then other bridges working with GBCA, like Mediawiki, etc.?

If this is practically possible, my opinion is that first the core 7 software should be revised thoroughly to make this core perfect for such external connections/communications/integration...

Related question: Doesn't there exist a uniform protocol how different programs can integrate? If so; the core better should already be build according to these characteristics. If not, maybe some developers can form a broad based group to get such a protocol into practice?

Thanks,

Ad

-- "We all declare for liberty; but in using the same word we do not all mean the same thing. With some the word liberty may mean for each man to do as he pleases with himself, and the product of his labor; while with others, the same word may mean for some men to do as they please with other men, and the product of other men's labor. Here are two, not only different, but incompatible things, called by the same name - liberty. And it follows that each of the things is, by the respective parties, called by two different and incompatible names - liberty and tyranny." --Abraham Lincoln