[spip-dev] RE: Re[2]: [Spip] Base autre que MySQL ?

Chacun de nos travaux ont été signalés sur la liste spip-dev, et nous
avons à chaque fois discuté des possibilités.

Cependant, l'utilisation de PEAR DB empêche la compatibilité avec
PHP3, donc il a été décidé de ne pas retenir nos travaux pour
l'instant.

ça serait vraiment dommage que ce travail reste dans les cartons, ou que
d'autres développeurs le refassent en parallèle.

Est-il possible de faire un "fork" au niveau de CVS et de faire une branche
parallèle à la 1.4.

Celle-ci deviendrait à terme (lors de l'abandon de php3) la 1.5 ou la 2.0.
La version 1.4 serait maintenue, les bugs corrigés sur la 1.4 seraient
reportés sur la branche parallèle.

Yves

PS: je crois que ADOdb est compatible PEARdb, mais propablement pas
compatible PHP3, est-ce que je me trompe ?

Est-il possible de faire un "fork" au niveau de CVS et de faire une
branche parallèle à la 1.4.

Celle-ci deviendrait à terme (lors de l'abandon de php3) la 1.5 ou la
2.0. La version 1.4 serait maintenue, les bugs corrigés sur la 1.4
seraient reportés sur la branche parallèle.

Tous les développements actuels vont a priori se faire sur la version
"standard" (compatible PHP3)... Il est peut-être possible d'ouvrir un
nouveau projet dans le CVS pour vous (Fil ?) mais de là à ce que ça
devienne une version régulière de SPIP....

Amicalement

Antoine.

Il est peut-être possible d'ouvrir un
nouveau projet dans le CVS pour vous (Fil ?) mais de là à ce que ça
devienne une version régulière de SPIP....

L'indépendance de SPIP par rapport aux SGBD ne t'intéresse pas ?

Perso, moi non plus (pour le moment) mais avoir un code objet pour l'accès à
la base ne mange pas de pain.

C'est vrai que le "quidam" n'a accès "qu'à" MySQL, et puisque c'est
l'objectif affiché de SPIP, pourquoi pas ?

Amicalement

Yves

Perso, moi non plus (pour le moment) mais avoir un code objet pour
l'accès à la base ne mange pas de pain.

Qui marche en PHP3 ? J'ai déjà fait un tour, je n'ai rien trouvé de
probant....

Bonjour,

Suite de l'épisode....
Ayant abandonné spip 1.4, aprés une semaine perdue pour un problème
d'authentification déconnante chez mon hébergeur (les cookies merdouilleux,
et l'accés impossible à la partie privée), j'ai installé spip 1.3.2, dont
l'accés à la partie privée sur cet hébergeur ést possible, via auth_http.

Voici mon nouveau problème, sans doute grâce à l'hébergeur rapidsite qui me
fait souffrir depuis un bout de temps:
Aprés installation, si je publie un article, le champ statut de certaines de
mes rubriques passe à 'prive' et mes articles, dans une boucle
(articles){id_rubrique}, ne s'affichent plus. Je précise que cela ne m'est
jamais arrivé en local, et que mon hébergeur a des soucis avec la mise en
place de cookies...

pour infos sur l'hébergeur: http://www.sorbonne-av.edu/phpinfo.php

Help :°-|
POURQUOI LE SORT S'ACHARNE-T-IL ?

jb

Perso, moi non plus (pour le moment) mais avoir un code objet pour
l'accès à la base ne mange pas de pain.

Qui marche en PHP3 ? J'ai déjà fait un tour, je n'ai rien trouvé de
probant....

oui, mais le passage de spip en php4 est annoncé pour dans 1 an.

Avez-vous une idée de la sortie de la future version ?
Avez-vous une liste de ce que vous voulez y intégrer ?

Amicalement,

Yves

moi je code toujours avec une sorte de "database abstraction layer" à deux francs : c'est hyper basique, meme pas orienté objet, mais ça a le merite de rendre tout développement indépendant du SGBD vu que ma fonction d'interface avec mysql (fonction db()) est ré-écrivable avec n'importe quel SGBD en une heure.

http://www.metacites.net/article71.html

si jamais ça peut aider.

stephane

Antoine wrote:

Re,

oui, mais le passage de spip en php4 est annoncé pour dans 1 an.

??? Il n'y a jamais eu d'annonce, juste une estimation, c'est tout.

Avez-vous une idée de la sortie de la future version ?

Non ;-))

Avez-vous une liste de ce que vous voulez y intégrer ?

Il y a un TODO mais c'est très indicatif.

http://rezo.net/spip-cvs/TODO.txt?rev=1.27&cvsroot=SPIP-DOC&content-type=text/vnd.viewcvs-markup

Nicolas Hoizey wrote:

Pour l'abstraction de BDD, le mieux serait de se servir d'un package
existant, genre PEAR::DB

PEAR::DB semble avoir trouvé une petite copine... :wink:

/////////////////////////////////////////////////
PEAR MDB is a merge of the PEAR DB and Metabase php database abstraction layers.

# MDB - Première version stable de PEAR MDB, Metabase Merger Database Abstraction Layer.
////////////////////////////////////

URL :
http://pear.php.net/package-info.php?pacid=54&release=1.0

a+
^Fabrice^^

> 1/ correction de tous les bugs (en cours) et stabilisation de la 1.4

La 1.4 est stable, on merdouille juste un peu sur la 1.4.1, mais c'est
parce qu'Antoine avait bu trop de coca-cola avant d'envoyer ses dernières
corrections. C'est aussi le charme de spip :slight_smile:

> 2/ en parallèle, travail sur la théorie de ce que sera spip 1.5,
> c'est à dire l'internationalisation, la couche d'interfaçage sur de
> mutliples DB, etc (voir le TODO).

Pour l'abstraction de BDD, le mieux serait de se servir d'un package
existant, genre PEAR::DB, donc il faut oublier la compatibilité avec
PHP3.

Show me the code, Luke! On a déjà centralisé toutes les requêtes, formaté la
syntaxe pour qu'elle soit (paraît-il) cohérente avec PEAR... normalement
l'intégration de PEAR devrait être l'affaire d'une heure de boulot, on peut
même rester compatible php3 si on en fait une option de spip (MySQL = php3,
pour utiliser PEAR php4 obligatoire). Non ?

Dans ce cas, il faut passer en version 2.x et non 1.5

Euh... :wink:

Si tu as besoin d'un peu plus de cheveux à couper en 4, je t'enverrai une
mèche :wink:

> 3/ implémentation de spip 1.5 à partir du boulot fait en amont, et
> donc arrêt de toute maintenance de spip 1.4 (excepté bug grave).

La version 1.4.X peut (et même doit) continuer à évoluer tant qu'il y
a des bugs, même mineurs, pour que ceux qui n'ont que PHP3 puissent
s'en servir.

Tant qu'on n'est pas bloqué, on continue à maintenir la compat php3. Par
exemple le surlignement n'est pas compat php3, mais ça n'empêche pas spip de
fonctionner... Pas besoin de créer des branches.

Si, tout de même, puisque les quelques discussions menées ici ont
montré la complexité de la tâche au niveau de la BDD, tâche qui
pourrait être grandement simplifiée par l'usage d'objets correspondant
aux types de données.

Euh, à quoi fais-tu référence ? Je n'ai pas suivi cette ddiscussion ?

-- Fil

La 1.4 est stable, on merdouille juste un peu sur la 1.4.1, mais
c'est parce qu'Antoine avait bu trop de coca-cola avant d'envoyer
ses dernières corrections. C'est aussi le charme de spip :slight_smile:

Ouh la la, quelqu'un ici aurait-il la prétention de croire que
l'objectif "zéro bug" est atteignable ??? :stuck_out_tongue:

Pour l'abstraction de BDD, le mieux serait de se servir d'un
package existant, genre PEAR::DB, donc il faut oublier la
compatibilité avec PHP3.

Show me the code, Luke!

The code you already seen have... :wink:

On a déjà centralisé toutes les requêtes

Pas du tout ! Les requêtes sont dispersées un peu partout, ce ne sont
que les appels aux fonctions PHP qui sont centralisés. Là je parle
réellement des requêtes elles-même.

formaté la syntaxe pour qu'elle soit (paraît-il) cohérente avec
PEAR...

La syntaxe est en effet cohérente avec PEAR::DB, mais elle ne pourrait
pas ne pas l'être, de toute façon ... :wink:

normalement l'intégration de PEAR devrait être l'affaire d'une heure
de boulot

Ou en 2 secondes avec notre script "spip2pear.php" ... :smiley:

Bon, on ne l'a pas fait évolué depuis 2 mois, mais il n'y a à priori
pas trop de boulot pour qu'il soit mis à jour.

Mais intégrer PEAR::DB nécessite avant tout que les requêtes soient
compatibles avec les BDD visées, ce qui n'est pas le cas. Plusieurs
requêtes sont encore spécifiques MySQL.

C'est pour ça que passer par des objets simplifierait le boulot.

on peut même rester compatible php3 si on en fait une option de spip
(MySQL = php3, pour utiliser PEAR php4 obligatoire). Non ?

Ca oui, c'est possible.

Dans ce cas, il faut passer en version 2.x et non 1.5

Euh... :wink:

Si tu as besoin d'un peu plus de cheveux à couper en 4, je
t'enverrai une mèche :wink:

J'en ai bien assez, merci ... :wink:

Tout ce que je veux dire, c'est que si SPIP abandonne la compatibilité
avec PHP3, ce qui ne sera donc sans doute pas le cas, il faut montrer
ce changement majeur en changeant de majeur dans le numéro de version.

Tant qu'on n'est pas bloqué, on continue à maintenir la compat php3.
Par exemple le surlignement n'est pas compat php3, mais ça n'empêche
pas spip de fonctionner... Pas besoin de créer des branches.

Yep.

Si, tout de même, puisque les quelques discussions menées ici ont
montré la complexité de la tâche au niveau de la BDD, tâche qui
pourrait être grandement simplifiée par l'usage d'objets
correspondant aux types de données.

Euh, à quoi fais-tu référence ? Je n'ai pas suivi cette ddiscussion?

Différentes discussions à propos de PEAR::DB et des autres bases de
données que MySQL, dont principalement ce ###### d'Oracle avec ses
types de données pourris.

-Nicolas

Ou en 2 secondes avec notre script "spip2pear.php" ... :smiley:

téléchargeable à l'adresse ??? Google ne le connait pas, en tous cas.

Mais intégrer PEAR::DB nécessite avant tout que les requêtes soient
compatibles avec les BDD visées, ce qui n'est pas le cas. Plusieurs
requêtes sont encore spécifiques MySQL.

C'est pas ça le boulot de PEAR ? J'ai rien compris alors :wink:
Bon, enfin, rien n'interdit de lister les requêtes qui posent problème et de
les corriger... à vous de jouer...

Différentes discussions à propos de PEAR::DB et des autres bases de
données que MySQL, dont principalement ce ###### d'Oracle avec ses
types de données pourris.

Je pensais que la demande était plutôt sur postgresql et sur MySQL 3.22.
Oracle n'est pas une priorité (pas libre). Mais si on fonctionne avec
Oracle, ok, tant mieux, ça nous fera un argument de plus face à Vignette. :wink:

-- Fil

> normalement l'intégration de PEAR devrait être l'affaire d'une heure
> de boulot

Ou en 2 secondes avec notre script "spip2pear.php" ... :smiley:

Tu as ça ? C'est dans le scontrib ? Ca m'interesse !

> Si tu as besoin d'un peu plus de cheveux à couper en 4, je
> t'enverrai une mèche :wink:
J'en ai bien assez, merci ... :wink:

Tu veux un poil de barbe ? Ou un cheveu de 1m ? Comme ça, t'aura les 2
extrèmes :wink:

Tiens, en parallèle à cette discussion, on pourrait bientôt intégrer
de nouveaux squelettes (si ça vous plaît), vu que j'ai pas mal avancé
dessus avec l'aide de Grégory. Il ne reste plus que le plan du site,
la page pour poster les forums, et les documents.

Voir à http://rezo.net/~antoine/spip/

Sans vouloir détailler à mort, c'est à peu près valide HTML 4.truc,
et accessible. Le code HTML est réduit au plus simple : des <div>,
<ul>, <li>, <h1>... et presque rien d'autre. Tout le reste est en
feuille de style (ce qui permet des trucs sympas par exemple : si
vous demandez à votre navigateur d'imprimer la page, il choisira
automatiquement la feuille de style prévue pour l'impression, qui
affiche l'article sous une forme épurée, sans les pavés de
navigation...).

(Si vous utilisez un bon navigateur (Mozilla, pas IE), la colonne
de gauche est fixe, ce qui est bien pratique)

Ca pourrait faire l'objet d'une 1.4.2. :wink:

a+

Antoine.

C'est surtout que de nombreuses sociétés, de toutes tailles, commencent à
s'intéresser de près à SPIP pour remplacer leurs Vignettes et autres
gouffres à budget avec lesquels ils ne sont pas arrivés finalement à grand
chose en regard du coût.

Ce qui serait logique, c'est qu'elles financent un développeur qui ferait
le boulot pour la collectivité. Je ne suis pas candidat :wink:

-- Fil

Ce qui serait logique, c'est qu'elles financent un développeur qui
ferait le boulot pour la collectivité. Je ne suis pas candidat :wink:

C'est ce qu'ont déjà fait BDDP\Tequila\Interactive, pour qui nous
avons conçu un framework autour de SPIP, dont sont issus entre autre
l'éditeur WYSIWYG et le fameux 'spip2pear.php' que je donnerais sous
peu, et EDF R&D, pour qui nous avons développé notamment l'inclusion
d'éléments multimédia, ce qui a sans doute accéléré cela dans SPIP, et
la galerie qui sera j'espère adoptée prochainement ...

Nous conseillons toujours à nos clients de faire profiter SPIP des
évolutions que nous concevons pour eux, et en général c'est accepté,
puisqu'ils y ont aussi un énorme intérêt, celui de la compatibilité
ascendante.

Mais là je parle en tant que consultant Clever Age, ce que je suis le
jour, et non en tant que SPIPeur fou à titre personnel, ce que je suis
la nuit ... :wink:

-Nicolas

C'est ce qu'ont déjà fait BDDP\Tequila\Interactive, [...] et EDF R&D

J'oubliais aussi Viacom Outdoor, pour qui Abdoulaye avait développé la
petite barre d'aide à la saisie de marqueurs SPIP.

D'autres projets en cours, mais on n'en parlera que quand ils seront
finis, et si les clients l'acceptent, ce qu'ils font pour l'instant
toujours, preuve que l'usage du libre commence à être bien vécu même
par les grands ... :wink:

-Nicolas

PEAR::DB semble avoir trouvé une petite copine... :wink:
PEAR MDB is a merge of the PEAR DB and Metabase php database
abstraction layers.

Ce n'est pas une nouveauté, loin de là. Le boulot de Lukas Smith sur
MDB a débuté il y a plusieurs mois, et le résultat devrait être
compatible avec DB, ce qui permettra de l'enrichir avec une plus forte
abstraction tout en restant compatible.

-Nicolas