[spip-dev] Nouvelle interface pour les tâches de fond

Bonsoir à tous,

La démultiplication des endroits de déclenchement des taches de fond ayant causé qq problèmes, je viens de poster une nouvelle version de leur gestion, qui permet d'en moduler beaucoup plus
finement leur fréquence, leur ordre et leur nombre.
Elle evite de plus d'utiliser la fonction timeout qui reposait sur un verrou SQL qui pouvait poser des problèmes de synchronisation.

Je vous laisse découvrir les spécifications dans les commentaires du fichier inc_cron, principal fichier modifié.

Je m'excuse par avance si cette souplesse nouvelle commence par amener des régressions dans certains cas: n'hésitez pas à faire part des pbs rencontrés lors de sa mise en place.

A coté des demandes de corrections de bugs, cette question a suscité des interrogations un peu naïves, ce qui est pardonnable, et des affirmations aussi péremptoires que fausses voire diffamatoires, ce qui l'est moins. Je rappelle donc que les membres de l'équipe de développement doivent:

1. corriger les bugs;

2. réécrire le code devenu trop touffu à force d'ajouts, afin d'anticiper les bugs et faciliter les nouveaux ajouts à venir (qu'il soit bien clair que nous sommes les premiers à déplorer que le code de Spip ne soit pas toujours un exemple à distribuer dans les écoles);

3. se documenter sur les nouveaux ajouts possible, notamment en tenant leur rôle d'administrateurs de spip-contrib où figurent des idées fiables car ayant passé l'épreuve de l'implémentation et l'épreuve du plébiscite par un minimum de personnes (une expérience récente montre que c'est le seul moyen connu de se faire coopter par l'équipe de développement ;-));

4. discuter entre nous pour que ces ajouts débouchent sur une nouvelle version cohérente de Spip bien qu'issue des motivations de chacun qui ne sont pas nécessairement les mêmes et ne peuvent etre fondées que sur un épanouissement personnel étant donné le caractère bénévole de la chose;

5. que ce caractère bénévole sous-entend que nous avons aussi des obligations professionnelles qui peuvent se révéler prioritaires, ainsi que souvent, l'origine de Spip en témoigne, des activités militantes, et enfin que nous avons un certain souci du bien-être de nos compagnes, enfants, parents, amis qui n'utilisent pas nécessairement Spip mais nous sont au moins aussi chers que ses utilisateurs.

Tout ceci explique que nous n'avons AUCUN moment à consacrer aux mails relevant plutot du cours particulier sur l'implémentation de Spip (qui est l'enseignant et qui est l'enseigné n''étant d'ailleurs pas toujours clair) et encore moins aux attaques personnelles dont le seul effet est d'inciter à ne plus lire cette liste et donc à ne plus s'occuper que de notre propre usage de Spip.

Les messages soucieux de l'intérêt général sont eux, évidemment, toujours sollicités.
Ils sont heureusement les plus nombreux.

A bientot
      Emmanuel

salut Emmanuel

Ce qui suit, n'a rien de personnel, je me permet de rebondir sur ton message, suite et à cause de la philosophie que représente maintenant cette liste, je suis vraiment en train de m'interroger sur l'entraide d'antan, qui a fait aussi la force de la liste. Vous développer des nouvelles fonctionnalitées (très bien) sauf que pour les comprendres et les assimilées, il faut avoir votre cursus. J'aurais aimé savoir si les débutant ou autres personnes travaillant simplement sur et pour le web avec SPIP sont inclus dans votre développement ou simplement cela ce passe entre "adultes" et les autres ont s'en fichent. Si ce dernier est le cas, franchement je trouve ça vraiment regrettable, pour la liste, pour spip et je dirais même pour vous...

3. se documenter sur les nouveaux ajouts possible, notamment en tenant
leur rôle d'administrateurs de spip-contrib où figurent des idées
fiables car ayant passé l'épreuve de l'implémentation et l'épreuve du
plébiscite par un minimum de personnes (une expérience récente montre
que c'est le seul moyen connu de se faire coopter par l'équipe de
développement ;-));

Ou pour se documenter, il y a tellement de sites qui parle de SPIP et de la même chose que cela devient un casse tête.

4. discuter entre nous pour que ces ajouts débouchent sur une nouvelle
version cohérente de Spip bien qu'issue des motivations de chacun qui
ne sont pas nécessairement les mêmes et ne peuvent etre fondées que sur
un épanouissement personnel étant donné le caractère bénévole de la
chose;

entre adulte alors, car lorsque on propose (débutant ou autres utilisateurs) quelques chose, on a même pas un minimum de réponse.

5. que ce caractère bénévole sous-entend que nous avons aussi des
obligations professionnelles qui peuvent se révéler prioritaires, ainsi
que souvent, l'origine de Spip en témoigne, des activités militantes,
et enfin que nous avons un certain souci du bien-être de nos compagnes,
enfants, parents, amis qui n'utilisent pas nécessairement Spip mais
nous sont au moins aussi chers que ses utilisateurs.

Je suis d'accord avec toi à 80% pour le reste je ne savais pas que SPIP état une association avec des bénévoles, je pensais que nous étions des petits contributeurs.

Tout ceci explique que nous n'avons AUCUN moment à consacrer aux mails
relevant plutot du cours particulier sur l'implémentation de Spip (qui
est l'enseignant et qui est l'enseigné n''étant d'ailleurs pas toujours
clair) et encore moins aux attaques personnelles dont le seul effet est
d'inciter à ne plus lire cette liste et donc à ne plus s'occuper que de
notre propre usage de Spip.

Rédefinir l'accessibilité de la liste alors, je pense que c'est une nécessité, car je commence (et peut etre d'autres) à me sentir un peu exclu de vos problèmatique, c'est peut etre voulu.

Les messages soucieux de l'intérêt général sont eux, évidemment,
toujours sollicités.
Ils sont heureusement les plus nombreux.

J'espère que celui-ci le sera.

@plus

/ Karim

Oui.

Maintenant pour l'aspect "entre adultes", il faut rappeler que spip-dev, contrairement aux autres listes,
est consacré au développement de spip. Ca ne veut évidemment pas dire que seuls ceux capables d'écrire un système équivalent ont droit de s'y exprimer ou que ne tenons pas compte de l'avis des autres: simplement
si la réponse souhaitée implique un cours particulier à donner nous n'avons pas le temps.
Les avis constructifs sont les bienvenus, ils auront peut-etre un impact sur le développement,
mais espérer une réponse systématiuqe est illusoire car la simple arithmétique montre qu' "un minimum de réponse" multiplié par des centaines d'utilisateurs fait quand meme beaucoup

      Emmanuel

Déesse A. a écrit :

Bonsoir à tous,

La démultiplication des endroits de déclenchement des taches de fond ayant causé qq problèmes, je viens de poster une nouvelle version de leur gestion, qui permet d'en moduler beaucoup plus
finement leur fréquence, leur ordre et leur nombre.
Elle evite de plus d'utiliser la fonction timeout qui reposait sur un verrou SQL qui pouvait poser des problèmes de synchronisation.

Je vous laisse découvrir les spécifications dans les commentaires du fichier inc_cron, principal fichier modifié.

Je m'excuse par avance si cette souplesse nouvelle commence par amener des régressions dans certains cas: n'hésitez pas à faire part des pbs rencontrés lors de sa mise en place.

A coté des demandes de corrections de bugs, cette question a suscité des interrogations un peu naïves, ce qui est pardonnable, et des affirmations aussi péremptoires que fausses voire diffamatoires, ce qui l'est moins.

Je suis trés content que cette fonctionnalités clef de Spip soit reimplémentée de manière propre et modulaire.
J'avais posté une proposition, et je trouve que cette implémentation est effctivement plus "Spip", avec minimisation de l'usage de class et prefererance à l'usage de variables globales.
C'est un choix, et tant que ça marche, il n'y a pas à discuter.
Je ne comprends pas trop le système qui garanti que toutes les taches soit executé si une tache a un soucis et ne veut pas rendre la main, il faut que je regarde mieux le code.
Par contre, je ne comprends pas trop les allusions naïves et tout ça. Mais j'ai compris que je dois faire des contribs.

M.

Entièrement d'accord, mais juste pour te donner un exemple, tout le boulot de titan que tu as effectuer cet été, j'aurais simplement trouver agréable de trouver de simples explications (tu vas peut-etre prévu de la faire ou c'est déjà fait, mais où trouver l'info) sur le boulot et qu'est ce que cela amène de nouveaux ou mieux par rapport à avant, c'est tout.

Sans donner de cours particulier, cela va de soit...

@plus

Les messages soucieux de l'intérêt général sont eux, évidemment,
toujours sollicités.
Ils sont heureusement les plus nombreux.

J'espère que celui-ci le sera.

Oui.

Maintenant pour l'aspect "entre adultes", il faut rappeler que spip-dev, contrairement aux autres listes,
est consacré au développement de spip. Ca ne veut évidemment pas dire que seuls ceux capables d'écrire un système équivalent ont droit de s'y exprimer ou que ne tenons pas compte de l'avis des autres: simplement
si la réponse souhaitée implique un cours particulier à donner nous n'avons pas le temps.
Les avis constructifs sont les bienvenus, ils auront peut-etre un impact sur le développement,
mais espérer une réponse systématiuqe est illusoire car la simple arithmétique montre qu' "un minimum de réponse" multiplié par des centaines d'utilisateurs fait quand meme beaucoup

      Emmanuel

/*
karim belkacem
graphiste / web designer / webmaster
tél. 01 44 90 99 76 / port. 06 81 83 75 63
email. kbelkacem@wanadoo.fr
messenger. karimage@hotmail.com
*/

Salut,

pour ma part, j'ai l'impression qu'il y a un probléme sur cette liste actuellement lié au fait qu'il y ait vraiment beaucoup de nouveauté sur la version beta: si quelqu'un ne comprends pas les nouvelles fonctionalités, il doit poster ici, et pas sur la liste user, parce que c'est encore une beta, et que sur la liste user, ca fait peur aux gens qui ont pas la beta.

Mais si il poste son probléme sur cette liste, c'est aussi un peu deplacé, parce que les devs ont autre chose à faire.

J'ai moi même beaucoup de travail et je comprends que tout le monde n'ai pas le temps de poster une reponse à tout les messages. Ce que j'observe, c'est que les propositions de code, patch, etc... de non developpeurs sur cette liste passent parfois inapercus et finissent par être perdu.
Ca revient à la discusion sur le gestionaire de bug. Pourquoi n'y a-t-il pas un endroit (spip-contrib) où le suivit de tout cela est fait, au moins pour la mémoire?

Je veux dire, ecrire une contrib, cela suppose le temps de l'ecrire, mais aussi que le code soit deja là. Ca ne me motive pas du tout d'ecrire des contribs et du code, si dans deux semaines la version sur laquelle il se repose sera obsoléte et que personne n'en veut vraiment.

Je pense que la sortie d'une version stable simplifiera cela aussi, parce qu'on pourra ecrire une contrib sur une base "stable", par sur la version cvs du 18 à 9h du mat :smiley:

Ma question s'adresse donc peut être plutôt aux admins de spip-contrib pour savoir s'il y a pas moyen d'ajouter une rubrique "proposition de bonne volonté", où l'on puisse vraiment faire un suivit de l'interet de "futur/hypothetique" contribs.

Pierre

karim Belkacem wrote:

karim Belkacem a écrit :

Entièrement d'accord, mais juste pour te donner un exemple, tout le boulot de titan que tu as effectuer cet été, j'aurais simplement trouver agréable de trouver de simples explications (tu vas peut-etre prévu de la faire ou c'est déjà fait, mais où trouver l'info) sur le boulot et qu'est ce que cela amène de nouveaux ou mieux par rapport à avant, c'est tout.

Sans donner de cours particulier, cela va de soit...

Karim, as tu regardé le texte des contribs d'Emmanuel dans l'espace privé de spip-contrib ? Es tu allé voir ce que les utilisateurs ont déjà retranscrit comme doc sur le wikki.

C'est le point de départ je pense.

Oui, c'est très juste. Ca devrait normalement ne pas durer encore trop longtemps.

Maintenant, l'impact sur la perennité des contributions me semble faible:
d'une manière générale Spip vise la compatibilité avec les versions passées.
Le pb est limité aux contributions qui exploite l'état du code a une date donnée
au lieu de se définir une interface claire facilement redéployable;
mais c'est la règle avec une beta.

      Emmanuel

Pierre Andrews a écrit :

Salut,

pour ma part, j'ai l'impression qu'il y a un probléme sur cette liste actuellement lié au fait qu'il y ait vraiment beaucoup de nouveauté sur la version beta: si quelqu'un ne comprends pas les nouvelles fonctionalités, il doit poster ici, et pas sur la liste user, parce que c'est encore une beta, et que sur la liste user, ca fait peur aux gens qui ont pas la beta.

Mais si il poste son probléme sur cette liste, c'est aussi un peu deplacé, parce que les devs ont autre chose à faire.

Il n'y a pas que des devs sur cette liste, tout le monde peut répondre.
Le problème viendrait plutot les questions qui arrivent sans que l'auteur n'ai fait de recherche préalable, il faut comprendre que cette liste est une liste de travail, le café du commerce c'est plutot la liste des utilisateurs voire sur les forums de spip-contrib. Et c'est très bien comme ca :).

J'ai moi même beaucoup de travail et je comprends que tout le monde n'ai pas le temps de poster une reponse à tout les messages. Ce que j'observe, c'est que les propositions de code, patch, etc... de non developpeurs sur cette liste passent parfois inapercus et finissent par être perdu.
Ca revient à la discusion sur le gestionaire de bug. Pourquoi n'y a-t-il pas un endroit (spip-contrib) où le suivit de tout cela est fait, au moins pour la mémoire?

Dans le temps c'etait Fil la mémoire :), mais on peut envisager d'étendre le système des contribs non publiées à ce genre de propositions de petits patchs si vous pensez que c'est utile : la rubrique pour les regrouper existe déjà dans le secteur interne de spip-contrib, elle s'appelle spip-à-brac :), on y place ce qui n'a pas de place ailleurs.

BoOz

BoOz wrote:

Pierre Andrews a écrit :

Salut,

pour ma part, j'ai l'impression qu'il y a un probléme sur cette liste actuellement lié au fait qu'il y ait vraiment beaucoup de nouveauté sur la version beta: si quelqu'un ne comprends pas les nouvelles fonctionalités, il doit poster ici, et pas sur la liste user, parce que c'est encore une beta, et que sur la liste user, ca fait peur aux gens qui ont pas la beta.

Mais si il poste son probléme sur cette liste, c'est aussi un peu deplacé, parce que les devs ont autre chose à faire.

Il n'y a pas que des devs sur cette liste, tout le monde peut répondre.
Le problème viendrait plutot les questions qui arrivent sans que l'auteur n'ai fait de recherche préalable,

On peut tous répondre, mais quand quelqu'un dit qu'il ne trouve pas une doc claire sur le nouveau compilo, je peux le comprendre. La doc a été écrite par les devs (la contrib d'emmanuel par exemple) ou ceux qui tournent autour de cette liste (le wiki, auquel je participe par exemple). Je peux alors comprendre que la doc ne soit pas toujours parfaitement "claire" pour un néophite :wink:

il faut comprendre que cette liste est une liste de travail, le café du commerce c'est plutot la liste des utilisateurs voire sur les forums de spip-contrib. Et c'est très bien comme ca :).

oui oui, mais c'est aussi une liste de travail sur comment travailler et quelles pistes "phylosophiques" suivrent, non? :wink:

J'ai moi même beaucoup de travail et je comprends que tout le monde n'ai pas le temps de poster une reponse à tout les messages. Ce que j'observe, c'est que les propositions de code, patch, etc... de non developpeurs sur cette liste passent parfois inapercus et finissent par être perdu.
Ca revient à la discusion sur le gestionaire de bug. Pourquoi n'y a-t-il pas un endroit (spip-contrib) où le suivit de tout cela est fait, au moins pour la mémoire?

Dans le temps c'etait Fil la mémoire :), mais on peut envisager d'étendre le système des contribs non publiées à ce genre de propositions de petits patchs si vous pensez que c'est utile : la rubrique pour les regrouper existe déjà dans le secteur interne de spip-contrib, elle s'appelle spip-à-brac :), on y place ce qui n'a pas de place ailleurs.

hmm :smiley:

Pierre

Bonjour,

Je pense que plus on sera sur cette liste dev et plus les niveaux de
chacuns seront différents et plus il y aura d'incompréhensions... etc.

La multiplicité des outils : listes, wiki, site et pourquoi pas un blog
bientôt qui sait ??? (au passage, il me semble que le spip mag serait
mieux sous cette forme de blog non ?)

je ne suis pas certains qu'il y ait de recette miracle entre les dev,
les anciens : :wink: , les nouveaux dev qui apportent les point de vue et
leur contribution (ex Emmanuel), les dev occasionnels, les débugueurs
fous, ceux qui comme moi testent à leur niveau et font remonter les
difficultés qu'ils rencontrent etc.

Peut-être que l'erreur est de créer des listes par typologie de public,
peut-être vaudrait-il mieux s'attacher plus à l'outil en terme de liste :

- liste spip user : très bien ne rien changer, c'est la liste pour la
version officielle actuelle et celles qui l'ont précédés.
- liste spip en cours : la liste pour la version en cours de dev
- liste spip futur : la liste pour des propositions ou des visions du
futur spip
- et peut-être même une liste spip philosophie pour avoir la discussion
que nous avons en ce moment, pus celle sur l'éthique qui revient
régulièrement quand il s'agit de parler de sujets sensible (ex : mot clé
sur auteurs etc.)

c'est certainement idiot de raisonner par l'outil plutot que par
public... mais les coups de gueules sur cette liste sont de plus en plus
nombreux...

De plus si certains posent des questions avant même d'avoir chercher la
réponse c'est qu'il n'est pas toujours facile de savoir où chercher la
réponse... les outils sont un peu trop nombreux.

A mon avis toujours, le site spip.net n'est pas assez centralisateur, il
faudrait qu'il explique clairement dès la page d'accueil tous les outils
à disposition des utilisateurs avec des renvois immédiats...

C'est ma vision des choses, qui n'est certainement pas parfaite...

Merci

A+

Pierre Andrews a écrit :

jl-grellier@cr-limousin.fr a écrit :

De plus si certains posent des questions avant même d'avoir chercher la
réponse c'est qu'il n'est pas toujours facile de savoir où chercher la
réponse... les outils sont un peu trop nombreux.

Assez d'accord.

Dans la liste des "ya'ka", un truc qui serait bien (et qui allégerait peut-être un peu la pression des questions toujours les mêmes sur les listes), c'est d'améliorer l'effiacité des outils de recherche disponibles (notamment dans les listes: le moteur de gmane, c'est comme même pas le top du top), voire de centraliser un outil de recherche sur les principales sources d'information spipienne.

François

François Schreuer a écrit :

jl-grellier@cr-limousin.fr a écrit :

De plus si certains posent des questions avant même d'avoir chercher la
réponse c'est qu'il n'est pas toujours facile de savoir où chercher la
réponse... les outils sont un peu trop nombreux.
   
Assez d'accord.

Dans la liste des "ya'ka", un truc qui serait bien (et qui allégerait peut-être un peu la pression des questions toujours les mêmes sur les listes), c'est d'améliorer l'effiacité des outils de recherche disponibles (notamment dans les listes: le moteur de gmane, c'est comme même pas le top du top), voire de centraliser un outil de recherche sur les principales sources d'information spipienne.

François

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
irc://irc.freenode.net/spip

un meta moteur qui interroge le moteur de spip-contrib, du lab et du spip officiel, avec en plus l'indexation des newsgroups.
Beau challenge, mais rien d'infaisable. Il faut une interface distante genre XML-RPC ou SOAP, ou à la traditionnel, en regex dans le HTML?

M.

Mathieu Lecarme a écrit :

François Schreuer a écrit :

jl-grellier@cr-limousin.fr a écrit :

De plus si certains posent des questions avant même d'avoir chercher la
réponse c'est qu'il n'est pas toujours facile de savoir où chercher la
réponse... les outils sont un peu trop nombreux.
  

Assez d'accord.

Dans la liste des "ya'ka", un truc qui serait bien (et qui allégerait peut-être un peu la pression des questions toujours les mêmes sur les listes), c'est d'améliorer l'effiacité des outils de recherche disponibles (notamment dans les listes: le moteur de gmane, c'est comme même pas le top du top), voire de centraliser un outil de recherche sur les principales sources d'information spipienne.

François

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
irc://irc.freenode.net/spip

un meta moteur qui interroge le moteur de spip-contrib, du lab et du spip officiel, avec en plus l'indexation des newsgroups.
Beau challenge, mais rien d'infaisable. Il faut une interface distante genre XML-RPC ou SOAP, ou à la traditionnel, en regex dans le HTML?

M.

juste pour completer.
Aprés le RSS pour syndiquer le contenu de plusieurs sites, une API distante pour acceder à des fonctions du site.
Un peu comme ce que fait Google ou Amazon. Il existe une bibliothèque SOAP pour PHP trés correct : http://dietrich.ganx4.com/nusoap/index.php
La syndication de recherche ne serait qu'une possibilitée.
Il existe d'ailleur une norme pour ça, c'est utilisé par Apple et Mozilla : http://mycroft.mozdev.org/download.html

M.

Pour mémoire, avant la Beta, SPIP avait une séduction certaine :
tel quel, servi clé en main, il permet à tous -y compris grand public-
de construire un site plein arome,
, et cependant, miracle, tous les sites sont différents,
, et, re-miracle, le pro y trouve aussi son compte
et peut épanouir sa compétence.
Mais cette compétence, il l'exprimait EN DEHORS de spip :
par le design, ou par le PHP sur mesure.

Je crois que c'était cela le bon goût SPIP :
un outil puissant et non limitant,
dont TOUTES les parties étaient accessibles à tous.

C'est ainsi qu'au printemps 04, les trucs de programmerz SPIP non documentés
se comptaient sur les doigts de la main.
Puis il y a eu les #EXTRA vraiment extra,
qui après quelques mois ont quand même eu leur doc sur le OFF de spip-contrib.
Puis il y a eu Agora et l'attroupement des $$II sur la scène SPIP.
Emulation entre programmerz ? Agora a précédé de peu la Beta CVS :
un SPIP non documenté qui fourbit des hi-fonctionnalités ...
réservées aux programmerz assidus.

Certes, cela s'accompagne dans la société d'une banalisation
de l'outil informatique et de la programmation,
néanmoins, il est certain que ça ne profitera qu'à une élite.

Alors je comprend bien le malaise des simple usagers
habitués à tout partager en camarades à la table des maîtres.
Angoisse : "la beta annonce-t-elle un SPIP à 2 vitesses ?"
... et l'avidité carnassière des programerz ou leur rage impuissante,
selon.

"Pourtant le Web indépendant et contributif est menacé ;
menacé par la fuite en avant technologique
qui rend la création de sites de plus en plus complexe et chère"
et l'heure est plus que jamais aux développement d'outils puissants
...et pleinement accesibles à tous.

JLuc