spipesque

[0d2c1616c9a2b7c24a96]

Je réfléchis à l"utilisation possible de SPIP dans une démarche de gestion
des connaissances, knowledge management pour être plus "in" et cet aspect
"participant" par messagerie "interne me séduit.

je vois les choses comme ça:
-un article est soumis en lecture aux peer rewieveers, les copains qui
corrigent !, n'est ce pas que quand on veut faire compliqué on peut!

-les copains peuvent être volontaires ou sélectionnés par l'auteur qui veut
travailler avec un petit groupe
d'ou le concept de messages à l'intérieur d'un petit groupe accessible via
comme le dis antoine, un "composer" avec sélection d'un ou plusieurs
destinataires par control clic.

-celà peut être ensuite soumis au groupe tout entier puis publiés mais on a
le travail en groupe restreint puis deuxième niveau élargi au groupe
d'auteurs du site, puis troisième niveau publié.....

Ce principe me paraît une méthode travail intéressante applicable à tous les
groupes de reflexions de toutes les disciplines et complémentaire du travail
de publication "coopératif" défini par ARNO.

Maurice
----- Original Message -----
From: "Antoine Pitrou" <pitrou@free.fr>
Cc: "spip-dev" <spip-dev@rezo.net>
Sent: Saturday, August 25, 2001 1:33 AM
Subject: Re: [spip-dev] spipesque

Fil wrote:
>
> * messagerie : l'éparpillement des messageries (une par site SPIP, à

tout le

> moins) est un peu pénible : il faut se rendre sur les parties

ecrire/

> d'une dizaine de SPIPs pour voir si on a de nouveaux messages : arg!
> Peut-être qu'une passerelle vers le mail avec Headers corrects pour
> trier, serait une solution (à chaque rédacteur de choisir s'il veut
> recevoir par mail) ?

Qu'appelles-tu Header corrects ? Tu avais soulevé, pendant la réunion
(super soirée au fait, merci :-)), le problème de l'utilité même de
la messagerie. Y a plusieurs trucs :

- Interface pas complète. Notamment, pas possible de supprimer un
message dont tu n'es pas expéditeur. Et puis, pour écrire à quelqu'un,
obligé de trouver son nom quelque part et de cliquer sur le bidule
vert à côté (au lieu de pouvoir faire "composer" et ajouter directement
le nom du destinataire).

- Est-ce que ça ne sert pas principalement à des choses qui pourraient
tout aussi bien se faire par mail ? Au vu de l'utilisation actuelle
dans uzine, j'en ai l'impression....

- Problème pour la sauvegarde de la base : faut l'implémenter. Or, la
relation spip_auteurs_messages n'étant pas simple (y a des colonnes
en plus), va falloir bidouiller, ce qui ne me plaît pas trop (et ne
m'intéresse pas des masses non plus ;-)).

- Accessoirement, ça crée une messagerie qui donne l'impression d'être
privée mais dont le contenu est consultable par quiconque a accès direct
à la base de données.

Pour l'ensemble du groupware, j'avais commencé à essayer d'en discuter
pour étudier ça ensemble, j'avais même entamé un petit fichier
http://rezo.net/spip-dev/devel/groupware.txt

Le "lock" manuel d'un article est notamment très important.

> * accélérer encore (des idées en vrac)
> - supprimer le calcul des rubriques actives : pas très utile, pas

clair

> (au vu de la liste spip), gênant (quand on a une rubrique de brèves
> uniquement) et ralentissement

C'est quand même nécessaire pour éviter l'affichage de rubriques

"parasites",

ou privées (comme sur uzine par exemple). Je ne suis pas sûr d'autre part
que ça bouffe beaucoup : tu as essayé de mesurer en supprimant ce calcul ?
D'ailleurs je me rends compte que ce sera bien accéléré en mettant le

statut

en index (SELECT DISTINCT id_rubrique FROM spip_articles WHERE statut =

'publie',

eh oui !). D'autre part le nombre de requêtes ne peut pas être supérieur à
la profondeur maximale du site, qui même sur le diplo ne dépasse pas 6 ou

7.

> - passer $row dans genere_url_article($id_article) (pas compliqué, un

peu

> utile, je veux bien m'en charger, mais ça implique de modifier un

petit

> peu les sites existants et utilisant inc-urls.php3)

Mmmh, ça sert à quoi ? Le fait d'utiliser le descriptif est quand même
très marginal. De plus, rien ne dit que le $row soit disponible (appel
lors d'un lien du type [bidule->125] par exemple). Grosse bidouille
en perspective pour pas grand'chose....

A propos, la version installée sur le Diplo n'est toujours pas celle
qui optimise les champs d'article récupérés depuis la base (1.0.5) :
accélération des sommaires.

> - écrire en C une fonction externe pour la partie la plus lente (typo

?) ?

:))) idiot en effet dans le cadre d'un soft exclusivement PHP/MySQL.
De plus, ce n'est certainement pas l'interprétation PHP qui est
prépondérante dans typo() et propre(), mais l'exécution sous-jacente
des regexps.

> - prétraitements de la base ? (à étudier)

Eventuellement. Mais il faut bien voir que ce qui est pénalisant,
ce n'est pas tellement les appels à la base de données (sauf sur
des pages pleines d'infos : sommaires détaillés....) mais le
code PHP qui met tout ça en ordre. Il suffit de voir la différence
de rapidité entre une page du site public et la page équivalente
dans ecrire (i.e. même taille de texte, même nombre de forums...).

> - mots-clés sur brèves

:))

Sinon il y a une demande qui revient très très souvent : gestion
d'un site multilingue. Sans aller jusqu'à pouvoir avoir plusieurs
versions d'un même article, on pourrait régler la langue des articles
(en plus c'est indispensable en vue d'éventuellement un jour avoir
plusieurs typos différentes en fonction de la langue) :

- une langue pour tout le site (configuration précise) : par défaut
le français
- éventuellement remplacée par une langue pour certaines rubriques
(héritée par les sous-rubriques et les articles)
- éventuellement remplacée par une langue pour certains articles

Donc une bête colonne MySQL en plus, avec l'interface qui va bien :
pop-up avec choix "langue par défaut" (sauf pour tout le site) ou
un paquet de langues définies "français, anglais..." (on doit
pouvoir récupérer la liste avec les codes ISO quelque part).

Possibilité de désactiver le multilingue dans la configuration
précise (désactivé par défaut ?).

Dans le site public, ajout d'un critère {lang} dans les boucles :
on peut ainsi avoir une partie multilingue, et puis le reste
géré de façon normale. S'il est présent, filtre selon la langue,
calculée de façon un peu particulière en examinant dans l'ordre :

- variable lang dans l'URL d'appel ($HTTP_GET_VARS['lang'])
- si pas, variable lang en cookie ($HTTP_COOKIE_VARS['lang'])
- si pas, langues acceptées par le navigateur ($HTTP_ACCEPT_LANGUAGE)

La variable lang et le cookie laissant le choix éventuel au
webmestre de fournir une sélection de langue explicite.
On pourra aussi forcer une langue dans les squelettes :
{lang=fr}.

Pour le calcul des langues de chaque rubrique, même type de
fonction que pour le calcul des... rubriques actives (désolé,
Fil ;-)). D'ailleurs, en réutilisant la même fonction, ça
ne devrait pas augmenter le temps d'exécution.

a+

Bises

Antoine.
_______________________________________________
spip-dev@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-dev