-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ad schrieb:
(I tried to respond on a particular message, but don't know how)
= = = = =
Thanks for all the feedback. Ofcourse; backwards programming doesn't make sense. But I encountered several sites running on core 5, because there isn't even an upgrade for the mods they need to core 6, or only a preliminary one. I'm not going to make a report of what I encountered (last 4 days uploading many-many mods); probably all here are familiar with the problem.
There are mods that have something about what I suggested, like this 'outdated' module I just encountered: http://drupal.org/project/crossite
Many usefull mods are written for 5 and never updated for 6, see for example this hyper-modern site that untill now only can run on 5: http://drupal.org/node/342472
That's unfortunate. But since it is Open Source you are talking about, you can also do something about it: Get somebody to take over that module and make a release for Drupal 6. If you can't do it yourself, pay somebody to do it.
So the question: what is outdated in these? Ofcourse the new core 7, not at all. But the whole package with the mods, will be literally outdated for one year, up to some years.
Why not getting crossite running again, in a new and broader & standardized form, for both 6 and 7? Maybe even changing the 7 core before the definitive first release, to anticipate for this development & make some transitions smoother? , IF SO:
1) one could run some parts on core 6 and others on core 7, for the first 2 years untill almost all necessary mods are on 7. Everyone could migrate inmediately to 7, so it would be a step forward with a smooth transition, not backward;
This would be an IT nightmare.
2) The same system (updated) can in future also be used for 7 to 8, so its not a one time case and lost creativity;
Just countless hours spent by IT people.
3) Several other web-programs have some bridge with Drupal, but quite amateuristic and no broad development support to get the basic/general API ready for all of these specific bridges (, communicators, exchangers, integrators a.s.o.).
That's probably because most of these bridges have very limited appeal to real Drupal users (the various forum bridges for example).
It might be web-worlds future hype, or already is with integrating gadgets, cellphones, twitter, facebook, groups, mediawiki and so on. Mediawiki was partly running, but with new releases it stopped running again, lacking a protocol for both Drupal and Mediawiki.
You can make a fine wiki using Drupal only and I bet there are ways to set up shared log in across both.
Yes, it is difficult to get the core optimized for this and make a sort of inter... protocol how programs best can bridge with as many aspects as possible. But because of the importance, to my opinion it should become a main developers community task to get done
Do we still need to wait untill core 8 for such a development? Actually I had a test site on 5 and had to wait 2 years before not even all required modules were up to date. So I might start soon in 6, but I'm still missing some features from 5. If possible, I recommend to start working on bridging even before the release of 7, examining if there better needs to be changes in the basics of core 7 first, to optimise for an additional 'general bridge API'.
To whome do you want to make your recommendations? Your proposal has two flaws: 1) There is probably nobody interested in executing it. 2) It probably won't work since all these projects work all in rather different ways. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAktDRaEACgkQfg6TFvELooQPjACfZMczuXYKnxxRU9TdCdQWnJAS qTEAmwct45Ue8ieBOpolBbUakYKc3+OA =AqpP -----END PGP SIGNATURE-----