[SPIP Zone] ref.xml , LookDeFiles

[765631639992b63b20d1]

Bouhhhh....
Personne fait rien de ce http://zone.spip.org/files/spip-zone/ref.xml ?

J'ai complété la description dans http://trac.rezo.net/trac/spip-zone/wiki/LookDeFiles

Comme indiqué dans les commits , c'est très boeuf , juste pour voir si ça pourrait convenir.
Dites moi si il faut changer ou ajouter quelque chose , pareil pour l'exploitation, ça doit pas être sorcier ce plugin xml , pis on peut le casser aussi

L'exploitation genre un plugin sur la zone serait parfaite , histoire qu'on puisse discuter.

à+
--
toggg

[anon3638017]

On 14 Dec, 2006, at 12:58, bertrand Gugger wrote:

Bouhhhh....
Personne fait rien de ce Connexion · GitLab ?

J'ai complété la description dans
http://trac.rezo.net/trac/spip-zone/wiki/LookDeFiles

Comme indiqué dans les commits , c'est très boeuf , juste pour voir si
ça pourrait convenir.
Dites moi si il faut changer ou ajouter quelque chose , pareil pour
l'exploitation, ça doit pas être sorcier ce plugin xml , pis on peut le
casser aussi

L'exploitation genre un plugin sur la zone serait parfaite , histoire
qu'on puisse discuter.

je veux faire un truc qui le transforme en fil rss pour me donner la description des nouveaux plugins ajoutés sur la zone, parce que j'en ratte plain et les messages dans les commits sont loin d'être explicite.

donc un rss produit à partir de ce ref.xml devrait faire ce que je veux (même s'il faudrait que le rss ne contienne que les derniers plugin.xml commité sur la zone.. mais bon, on s'en fout des standards

Dans la même idée, je voulais faire un rss par plugin qui donne un changeset à chaque nouvelle version/commit (a partir des messages des commits ou alors d'un fichier changeset), mais je pense pas que ref.xml soit suffisant pour cela, faudrait que je base plutôt cela sur l'historique svn.

Enfin, c'est juste des idées en l'air pour aider à suivre l'evolution des plugins et qui devront attendre les vacances pour que je m'y interesse plus profondément.

Pierre

[touti]

bertrand Gugger a écrit :

Bouhhhh....
Personne fait rien de ce Connexion · GitLab ?

J'ai complété la description dans http://trac.rezo.net/trac/spip-zone/wiki/LookDeFiles

Comme indiqué dans les commits , c'est très boeuf , juste pour voir si ça pourrait convenir.
Dites moi si il faut changer ou ajouter quelque chose , pareil pour l'exploitation, ça doit pas être sorcier ce plugin xml , pis on peut le casser aussi

L'exploitation genre un plugin sur la zone serait parfaite , histoire qu'on puisse discuter.

à+
  

je l'ai bien vu ton bô xml, excuse moi, je suis grippé avec torticolis qui me brocolis
j'essaie de voir dès que je peux,
comme pierre, je pense plutôt à un rss,
et un beau squelette qui va avec,
pas sur que j'ai les compétences, je regarde ça, merci en tout cas

[765631639992b63b20d1]

Pierre Andrews wrote:

On 14 Dec, 2006, at 12:58, bertrand Gugger wrote:

Bouhhhh....
Personne fait rien de ce Connexion · GitLab ?

J'ai complété la description dans
http://trac.rezo.net/trac/spip-zone/wiki/LookDeFiles

Comme indiqué dans les commits , c'est très boeuf , juste pour voir si
ça pourrait convenir.
Dites moi si il faut changer ou ajouter quelque chose , pareil pour
l'exploitation, ça doit pas être sorcier ce plugin xml , pis on peut le
casser aussi

L'exploitation genre un plugin sur la zone serait parfaite , histoire
qu'on puisse discuter.

je veux faire un truc qui le transforme en fil rss pour me donner la description des nouveaux plugins ajoutés sur la zone, parce que j'en ratte plain et les messages dans les commits sont loin d'être explicite.

donc un rss produit à partir de ce ref.xml devrait faire ce que je veux (même s'il faudrait que le rss ne contienne que les derniers plugin.xml commité sur la zone.. mais bon, on s'en fout des standards

De toute façon , là c'est vraiement fait gros boeuf , je vais tout recasser , peut être réécrire en php qu'on puisse causer.
Je suis mécontent car j'ai incorporé dans le projet parti du simple perl ancestral basé uniquement sur archivelist.txt les références de tous les plugin.xml et theme.xml.
Je l'ai fait vite fait à l'époque , et là je rajoute vite fait une sortie xml.
C'est pas satisfaisant aussi bien pour la consomation des ressources des gentilles machines où ça tourne que pour la bande et la facilité de présenter.

Il y a beaucoup de paquets , (machin.xml ou de archivelist.txt) mais finalement , peu d'entre eux changent d'une 1/2 heure ou d'un jour sur l'autre.

Je pense donc ne générer que la liste des sous-dossiers référencés du svn qui auront changé.
Le tout restant point par point dans un cache fichier.
De là tirer les 10, 20, 50 ... derniers, triés par date / présence dans archivelist.txt
Je veux dire, avec 1 ou 2 listes spéciales pour ce qui est déclaré dans archivelist.txt
Ensuite, s'il faut rajouter 2 ou 3 octets de texte pour que ça ait la bonne tronche , ç'est pas un problème.

Dans la même idée, je voulais faire un rss par plugin qui donne un changeset à chaque nouvelle version/commit (a partir des messages des commits ou alors d'un fichier changeset), mais je pense pas que ref.xml soit suffisant pour cela, faudrait que je base plutôt cela sur l'historique svn.

Une chose que j'ai déjà citée , il me semble qu'on en avait discuté +/- avec James , c'est que finalement , on base énormément sur archivelist.txt donc il serait possible sans gros changement de travailler avec une archivelist.txt custom propre à une installation.
Disons, surveiller les paquets qui t'intéressent depuis une repos partielle à toi.

Enfin, c'est juste des idées en l'air pour aider à suivre l'evolution des plugins et qui devront attendre les vacances pour que je m'y interesse plus profondément.

Heh moi, c'est le travail que j'attends.
--
toggg

[touti]

bertrand Gugger a écrit :

Pierre Andrews wrote:
  

On 14 Dec, 2006, at 12:58, bertrand Gugger wrote:

Bouhhhh....
Personne fait rien de ce Connexion · GitLab ?

J'ai complété la description dans
http://trac.rezo.net/trac/spip-zone/wiki/LookDeFiles

Comme indiqué dans les commits , c'est très boeuf , juste pour voir si
ça pourrait convenir.
Dites moi si il faut changer ou ajouter quelque chose , pareil pour
l'exploitation, ça doit pas être sorcier ce plugin xml , pis on peut le
casser aussi

L'exploitation genre un plugin sur la zone serait parfaite , histoire
qu'on puisse discuter.
      

je veux faire un truc qui le transforme en fil rss pour me donner la description des nouveaux plugins ajoutés sur la zone, parce que j'en ratte plain et les messages dans les commits sont loin d'être explicite.

donc un rss produit à partir de ce ref.xml devrait faire ce que je veux (même s'il faudrait que le rss ne contienne que les derniers plugin.xml commité sur la zone.. mais bon, on s'en fout des standards
    

De toute façon , là c'est vraiement fait gros boeuf , je vais tout recasser , peut être réécrire en php qu'on puisse causer.
Je suis mécontent car j'ai incorporé dans le projet parti du simple perl ancestral basé uniquement sur archivelist.txt les références de tous les plugin.xml et theme.xml.
  
Je l'ai fait vite fait à l'époque , et là je rajoute vite fait une sortie xml.
C'est pas satisfaisant aussi bien pour la consomation des ressources des gentilles machines où ça tourne que pour la bande et la facilité de présenter.

Il y a beaucoup de paquets , (machin.xml ou de archivelist.txt) mais finalement , peu d'entre eux changent d'une 1/2 heure ou d'un jour sur l'autre.

Je pense donc ne générer que la liste des sous-dossiers référencés du svn qui auront changé.
Le tout restant point par point dans un cache fichier.
De là tirer les 10, 20, 50 ... derniers, triés par date / présence dans archivelist.txt
Je veux dire, avec 1 ou 2 listes spéciales pour ce qui est déclaré dans archivelist.txt
Ensuite, s'il faut rajouter 2 ou 3 octets de texte pour que ça ait la bonne tronche , ç'est pas un problème.
  

Je me trompe peut être mais l'idée ne serait il pas plutot de faire plusieurs fichiers xml rss (un pour themes, un autre pour plugins..)
basés sur le backend de spip avec même genre de DTD (item dc creator...)
avec des variables dans l'url par exemple pour choisir l'état (stable, dev...)
because ça me semble bien lourd (12500 lignes quand ^m)
et cela permettrait de syndiquer dans n'importe quel site spip,
de se servir du parser spip et faire une recup html soit via un squelette special
soit intégré dans admin_plugin
evidemment non testé tout ça!

Dans la même idée, je voulais faire un rss par plugin qui donne un changeset à chaque nouvelle version/commit (a partir des messages des commits ou alors d'un fichier changeset), mais je pense pas que ref.xml soit suffisant pour cela, faudrait que je base plutôt cela sur l'historique svn.
    

Une chose que j'ai déjà citée , il me semble qu'on en avait discuté +/- avec James , c'est que finalement , on base énormément sur archivelist.txt donc il serait possible sans gros changement de travailler avec une archivelist.txt custom propre à une installation.
Disons, surveiller les paquets qui t'intéressent depuis une repos partielle à toi.
  

Enfin, c'est juste des idées en l'air pour aider à suivre l'evolution des plugins et qui devront attendre les vacances pour que je m'y interesse plus profondément.
    

Heh moi, c'est le travail que j'attends.
  

[765631639992b63b20d1]

bah...
Je me perd coté technique mais bon !
Y a des choses référencées dans archivelist.txt , mettons c'est ce que les gens estiment pouvoir zipper
Y a les plugin.xml , c'est a priori un truc intégrable direct comme plugin
Y a les theme.xml , je sais pas ce que c'est, certains en veulent

Ces trucs peuvent bien sur être dans toute combinaison, zip sans rien, plugin et theme mais pas zip , etc.

Tout ça fait pas beaucoup de lignes, en comptant brutalement, donc éventuellement double ou triple, 354.
[spip-zone]$ (find * \( -iname plugin.xml -o -iname theme.xml \) -print ; grep -P '^[^\s#]' archivelist.txt ) | wc -l
354

Je suis en train de rassembler les lignes , à savoir si zip , plugin , theme (+ ce qui viendra) , une seule ligne pour les combinaisons.
Faut voir , y a des zonards qui finnissent les répertoires avec / , d'autres pas et tout.

Enfin , les doubles ou triples réduits , ça fera pas 200 lignes.

Maintenant , il faut considérer le temps , sur ces 200 lignes , vraiement très peu changent d'une 1/2 heure , d'un jour voire d'une semaine à l'autre.
Plutôt que de répéter 200 svn info pour savoir que 190 n'ont pas changés , je pense m'orienter sur une technique à la svnup2tgz , en analysant le log de svn up.

Ensuite on mixe tout ça, les xml changés regénérés , les autres du cache.

Je désespère donc pas fournir des top-10 , top-20 , zip ou plugin/theme

Globalement, plus de choses et plus vite.
Si si
--
toggg