J'ai créé une fonction pour ajouter des jobs SPIP
y compris avec des délais incrémentaux entre chaque
et l'ai documentée ici : http://contrib.spip.net/spip_cron_ajoute
Actuellement cette fonction est autonome et peut être utilisée aussi
par des programmes à côté d'un SPIP, mais hors SPIP.
Elle ou sa soeur pourrait peut être aussi être intégrée à job_queue ?
JL
Hop,
Le 26/05/2014 16:26, JLuc a écrit :
J'ai créé une fonction pour ajouter des jobs SPIP
y compris avec des délais incrémentaux entre chaque
et l'ai documentée ici : spip_cron_ajouteActuellement cette fonction est autonome et peut être utilisée aussi
par des programmes à côté d'un SPIP, mais hors SPIP.
Cool.
Elle ou sa soeur pourrait peut être aussi être intégrée à job_queue ?
D'un point de vue fonctionnel, ça ne doublonne pas avec job_queue_add() ?
++
b_b
Bonjour,
Ce n'est pas ce que fait déjà
http://code.spip.net/autodoc/tree/ecrire/inc/queue.php.html#function_queue_add_jobcf.
http://core.spip.org/projects/spip/repository/entry/spip/ecrire/inc/queue.php#L50
ou
Connexion · GitLab?
Ybbet.
Le 26 mai 2014 16:26, JLuc <jluc@no-log.org> a écrit :
J'ai créé une fonction pour ajouter des jobs SPIP
y compris avec des délais incrémentaux entre chaque
et l'ai documentée ici : spip_cron_ajouteActuellement cette fonction est autonome et peut être utilisée aussi
par des programmes à côté d'un SPIP, mais hors SPIP.
Elle ou sa soeur pourrait peut être aussi être intégrée à job_queue ?JL
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 26/05/2014 16:35, Ybbet Spip a écrit :
Bonjour,
Ce n'est pas ce que fait déjà http://code.spip.net/autodoc/tree/ecrire/inc/queue.php.html#function_queue_add_job cf.
http://core.spip.org/projects/spip/repository/entry/spip/ecrire/inc/queue.php#L50
ou Connexion · GitLab ?
Le 26/05/2014 16:32, Bruno Bergot a écrit :
> D'un point de vue fonctionnel, ça ne doublonne pas avec job_queue_add() ?
> API de gestion de la file des travaux - Programmer avec SPIP 4
Il y a 2 aspects fonctionnels qu'on ne trouve pas dans l'existant :
- Il y a mention d'un délai, et non d'un time.
Cela évite de calculer localement le moment de l'envoi
et cela facilite donc la programmation de tâches multiples
lorsqu'elles doivent s'espacer d'un délai (dans l'exemple : l'envoi de lettres).
- cette fonction peut être proposée dans un fichier librairie php
qui ne nécessite aucun autre php, et en particulier ne nécessite pas d'inclure queue.php
ou queue_options.php ni de quelconques fichiers SPIP
et qui peut donc facilement être inclue dans des programmes non spip
(contrairement aux inclusions spip plus lourdes).
Ce serait donc un élément d'API autonome, permettant de communiquer avec SPIP,
mais ne nécessitant pas d'inclure tout le noyau SPIP.
(Existerait il d'autres éléments spip de ce type ? Je n'en ai pas vent)
Ces 2 fonctionnalités sont indépendantes et peuvent être retenues ou non,
de manière indépendante.
On pourrait d'ailleurs isoler la première dans une fonction dédiée,
en déportant le static $when dans cette fonction.
À un petit détail prés (le $time de la première tâche)
on aurait le même fonctionnement en mettant dans la fonction principale
$time = get_time_avec_delai ($delai),
avec
function get_time_avec_delai ($delai) { // 0 pour exec sans attente, ou délai en secondes entre jobs consécutifs
static $when;
if (!isset($when))
$when = 0;
// En cas d'appels successifs,
// si ya jamais de délai, $when reste à 0.
// Si ya un délai à un moment, $when s'ancre dans le temps à partir de là
if ($delai and !$when)
$when = time();
$when += $delai;
return $when;
}
JLuc
Ybbet.
Le 26 mai 2014 16:26, JLuc <jluc@no-log.org <mailto:jluc@no-log.org>> a écrit :J'ai créé une fonction pour ajouter des jobs SPIP
y compris avec des délais incrémentaux entre chaque
et l'ai documentée ici : http://contrib.spip.net/spip___cron_ajoute <http://contrib.spip.net/spip_cron_ajoute>Actuellement cette fonction est autonome et peut être utilisée aussi
par des programmes à côté d'un SPIP, mais hors SPIP.
Elle ou sa soeur pourrait peut être aussi être intégrée à job_queue ?JL
----
spip-zone@rezo.net <mailto:spip-zone@rezo.net> - http://listes.rezo.net/__mailman/listinfo/spip-zone
<http://listes.rezo.net/mailman/listinfo/spip-zone>----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 26/05/2014 16:59, JLuc a écrit :
Ce serait donc un élément d'API autonome, permettant de communiquer avec SPIP,
mais ne nécessitant pas d'inclure tout le noyau SPIP.
(Existerait il d'autres éléments spip de ce type ? Je n'en ai pas vent)
Il y avait cependant une espèce d'API qui passait par l'url.
Il me semble qu'il fallait appeler une adresse www.monsite.ext/api/xxxx.php?yyyyy
Je ne me souviens plus du nom de ce plugin ou de cette fonctionnalité.
Quelqu'un pourrait me raffraichir la mémoire ?
Sur plugins.spip.net, j'ai vu plusieurs plugins peut être en rapport:
xmlrpc, http (http abstrait), collectionjson .
Il n'y a pas de doc mais je ne crois pas reconnaître.
JL
Hello,
JLuc a écrit :
Le 26/05/2014 16:35, Ybbet Spip a écrit :
Bonjour,
Ce n'est pas ce que fait déjà
http://code.spip.net/autodoc/tree/ecrire/inc/queue.php.html#function_queue_add_job
cf.
http://core.spip.org/projects/spip/repository/entry/spip/ecrire/inc/queue.php#L50ou
Connexion · GitLab
?Le 26/05/2014 16:32, Bruno Bergot a écrit :
> D'un point de vue fonctionnel, ça ne doublonne pas avec
job_queue_add() ?
> API de gestion de la file des travaux - Programmer avec SPIP 4Il y a 2 aspects fonctionnels qu'on ne trouve pas dans l'existant :
- Il y a mention d'un délai, et non d'un time.
Cela évite de calculer localement le moment de l'envoi
et cela facilite donc la programmation de tâches multiples
lorsqu'elles doivent s'espacer d'un délai (dans l'exemple : l'envoi de
lettres).
Justement, cette notion de délai tel qu'interprété par ta fonction pose des problèmes pour être un argument d'entrée d'une API :
si deux appels successifs à la fonction sont réalisés par un même processus ou par des processus concurents on n'aura pas le même résultat, ce qui est un peu embêtant pour du web où l'on passe son temps à faire les choses dans des processus concurrents…
- cette fonction peut être proposée dans un fichier librairie php
qui ne nécessite aucun autre php, et en particulier ne nécessite pas
d'inclure queue.php
ou queue_options.php ni de quelconques fichiers SPIP
et qui peut donc facilement être inclue dans des programmes non spip
(contrairement aux inclusions spip plus lourdes).Ce serait donc un élément d'API autonome, permettant de communiquer avec
SPIP,
mais ne nécessitant pas d'inclure tout le noyau SPIP.
(Existerait il d'autres éléments spip de ce type ? Je n'en ai pas vent)
Mais ici, elle ne fonctionne que si SPIP utilise mysql, puisque ne passe pas par les API SQL de SPIP, ce qui là aussi est limitant pour en faire un point d'entrée d'une API
Au passage, les échappements de ta requête SQL ne sont pas tout a fait complets ni exacts - ce qui démontre aussi l'intérêt d'utiliser l'API SQL de SPIP. Il manque des échappements sur $function et $inclure, et le md5($arguments) est fait après échappement, ce qui ne donne pas forcement le bon résultat.
Cédric
Le 29/05/2014 17:14, Cédric Morin a écrit :
JLuc a écrit :
- Il y a mention d'un délai, et non d'un time.
Justement, cette notion de délai tel qu'interprété par ta fonction pose des problèmes pour être un argument d'entrée
d'une API : si deux appels successifs à la fonction sont réalisés par un même processus ou par des processus concurents
> on n'aura pas le même résultat, ce qui est un peu embêtant pour du web où l'on passe son temps à faire les choses
> dans des processus concurrents…
Oui en effet. La fonction, étant locale au processus appelant, ne gère pas les interférences avec des appels similaires éventuellement faits par les autres N processus concurrents. Ça fait comme si il y avait N files indépendantes, chacune considérant les autres comme un bruit de fond.
Mais même si c'était centralisé dans SPIP, il y aurait des files de jobs ailleurs, dans d'autres process systèmes ou applicatifs ne passant pas par SPIP. Peut-être ce n'est pas suffisamment important ou utile mais il me semble que la notion de délai a tout de même du sens localement. Le "résultat" attendu ici, c'est ni le moment exact, ni l'ordre d'exécution des tâches relativement à celles de processus différents, mais des délais à respecter avec les autres jobs envoyés par la même fonction :
"Applique cette fonction dés que possible (si délai=0) OU préserve un délai de tant de secondes après le précédent job appelé par cette fonction avant de l'exécuter (dans la 2eme version proposée) (ou après l'avoir exécuté, selon la 1ère version du carnet SPIP)."
Mais ici, elle ne fonctionne que si SPIP utilise mysql, puisque ne passe pas par les API SQL de SPIP, ce qui là aussi
est limitant pour en faire un point d'entrée d'une API
> Au passage, les échappements de ta requête SQL ne sont pas tout a fait complets ni exacts - ce qui démontre aussi
> l'intérêt d'utiliser l'API SQL de SPIP.
L'intérêt de l'API SQL de SPIP n'est plus à démontrer pour les codes des plugins 
Mais les API connues de SPIP sont des API *pour SPIP*, pas pour des programmes php NON SPIP ! (à moins que le truc en .../api/... )
Il manque des échappements sur $function et $inclure, et le md5($arguments) est
fait après échappement, ce qui ne donne pas forcement le bon résultat.
OK, j'ai corrigé sur le carnet Spip.
JLuc
Salut,
Le 29 mai 2014 à 15:59, JLuc <jluc@no-log.org> a écrit :
Le 26/05/2014 16:59, JLuc a écrit :
Ce serait donc un élément d'API autonome, permettant de communiquer avec SPIP,
mais ne nécessitant pas d'inclure tout le noyau SPIP.
(Existerait il d'autres éléments spip de ce type ? Je n'en ai pas vent)Il y avait cependant une espèce d'API qui passait par l'url.
Il me semble qu'il fallait appeler une adresse www.monsite.ext/api/xxxx.php?yyyyy
Je ne me souviens plus du nom de ce plugin ou de cette fonctionnalité.
Quelqu'un pourrait me raffraichir la mémoire ?Sur plugins.spip.net, j'ai vu plusieurs plugins peut être en rapport:
xmlrpc, http (http abstrait), collectionjson .
Il n'y a pas de doc mais je ne crois pas reconnaître.
C'est le plugin "http" qui fait cela grâce au vendor de Symfony: HttpFoundation :
----------
Ybbet
JL
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 30/05/2014 00:00, Ybbet SPIP a écrit :
C'est le plugin "http" qui fait cela grâce au vendor de Symfony: HttpFoundation :
Connexion · GitLab
Merci.
Donc c'est /http.api/ plutôt, d'après les commentaires de
Mais c'est en test, et sans doc c'est ardu !
Il ne devrait pas y avoir un morceau de htaccess livré avec ?
JL
Le 30/05/2014 12:42, JLuc a écrit :
Mais c'est en test, et sans doc c'est ardu !
Il ne devrait pas y avoir un morceau de htaccess livré avec ?
C'est bien déjà une fonctionnalité du htaccess de SPIP 3. Mais je ne vois pas du tout le rapport avec le truc de job queue.
--
RastaPopoulos
Le 30/05/2014 14:31, RastaPopoulos a écrit :
Le 30/05/2014 12:42, JLuc a écrit :
Mais c'est en test, et sans doc c'est ardu !
Il ne devrait pas y avoir un morceau de htaccess livré avec ?C'est bien déjà une fonctionnalité du htaccess de SPIP 3.
Ah c'est solide alors.
> Mais je ne vois pas du tout le rapport avec le truc de job queue.
Hmm Peut être fais je fausse route.
JL