[isf-wifidog] [AllianceCSF] Réunion de développement

Benoit Grégoire benoitg at coeus.ca
Ven 23 Oct 23:43:48 EDT 2009


On October 22, 2009, Carl-Frédéric De Celles wrote:
> Alexandre, je ne vois pas comment ni pourquoi nous allons perdre des
> fonctionnalités, personne n'a encore même vu une preuve de concept.

En fait personne n'a encore présenté de concept clair, ce qui n'aide pas à 
éviter les inquiétudes ;)

> Assez de temps perdu avec des choses non concrètes, prenons juste le
> temps de développer et livrer quelques choses, nous pourrons le
> bonifier après... Si ISF veut attendre que toutes les fonctionnalités
> soient dans Wordpress, vous attendrez pour l'installer, ce n'est pas
> un problème.

Bien d'accord: tout ce bitchage technologique collectif ne nous avance à rien.

Permettez-moi de présenter deux scénarios (et une solution): 

Scénario 1:

Tout ce qu'on veut c'est que Wifidog permette au choix de:
-Déterminer un url par hotspot (déjà supporté) ou
-Un url unique paramétrisé (REST) avec les infos dynamiques du hotspot (déjà 
supporté pour un iframe, 4 ou 5h de travail selon la richesse des paramètres 
voulus pour pouvoir remplacer le portail).

Tout le monde (à date) affirme haut et fort que leur vision ne se limite pas à 
ça.

Pourtant:
- Je sais très bien que ça ferait le bonheur d'un paquet de monde au sein de 
l'alliance et à l'extérieur, parce que ça réponds à tout les besoins qu'ils 
entrevoient.
- Ça permet de ré-utiliser un paquet d'outils >existants<, >maintenant< et 
>sans modification<.
- Le serveur d'authentification, malgré les prétentions de certains, n'a (du 
moins dans mon esprit) JAMAIS voulu être un CMS (au sens de l'endroit de 
prédilection où le contenu original est produit et entreposé). Toute 
initiative qui déplace un maximum de production de contenu (et de chicanes 
associées) hors de wifidog a ma plus totale bénédiction!

Selon moi, l'alliance devrait mettre son poids et ses ressources pour finaliser 
et exploiter ça AVANT tout API, module ou grand projet.  

De cette façon:
- Ceux qui n'ont pas de visées locatives sophistiquées seront satisfaits, et 
ne seront pas retardés.
- Les fans des différents CMS pourront travailler sur des preuves de concepts 
pour démontrer les forces de leurs différents outils, voire les mettre en 
production, plutôt que d'en débattre.

Soyons réalistes, les fonctionnalités de gestion locatives des grands CMS en 
sont à leur balbutiement.  Si l'avenir est là, il faut commencer par exploiter 
ce qui existe (augmenté d'une position géographiques certaine) avant de 
vouloir les combiner avec des fonctions temporelles, historiques et géomatique 
plus sophistiquées et qui peuvent changent parfois fondamentalement 
l'architecture d'information sur laquelle un CMS est construits (Regardez le 
temps qu'il faut pour que les dévelopeurs des différents CMS s'entendent sur la 
manière de supporter le multilinguisme...).

Ce scénario à l'avantage que:

- La bouchée est plus que modeste
- Elle ne nuit aucunement au futur, et n'enlève rien à qui que ce soit.
- Dans 3 semaines les groupes qui le veulent auront de nouveaux portails 
construits avec leur CMS favori et leur expertise actuelle, et on pourra voir 
en >pratique< ce qui chacun a a offrir en matière locative, et en >pratique< ce 
qui manque dans un API pour aller plus loin. 


Scénario 2:

Si l'Alliance a des visées beaucoup plus grande au niveau du contenu locatif 
et ce >à court terme<, la question n'est pas de savoir (pour l'instant) la 
syntaxe exacte ou le format de donnée (XML ou JSON), mais bien d'en déterminer 
la mécanique:

- Est-ce que chaque CMS implantant le protocole à développer est responsable 
des calculs géomatique du contenu locatifs (ie:  je veux les trois entrées les 
plus proche du contenu A, les 5 entrées dans un rayon de 1 km du contenu b, et 
les 4 entrées ayant été produite à ce hotspot du contenu C).  Si non, par quel 
protocole demande t'il ces informations (il y en a plusieurs existants, 
faudrait mettre notre poids derrière l'un d'entre eux, ou en développer un 
nouveau.  Dans les deux cas, il n'y a rien de spécifique à wifidog la dedans.).
- L'interface de login de l'usager doit-elle pouvoir être délégué au CMS, et 
si oui par quel mécanique.
- Veux-t'on pouvoir diffuser du contenu avant le login de l'usager?  Auquel cas 
le serveur de contenu doit pouvoir dire au serveur d'authentification tout les 
serveur dont il dépends (ex: google maps) AVANT l'affichage de la première page.
- Comment partage t'on l'identifiant de session entre les système
- Qui centralise les informations de profils, et jusqu'à quel degré (simple url 
ou informations lisibles informatiquement)
- Les informations de session de l'usager doivent-ils être partagé entre plus 
d'un système de gestion de contenu.
- Quel système est responsable d'enregistrer les la date, lieu, usager et 
identifiant d'un éléments de contenus déjà visualisé (c'est bien le fun pour 
les stats (savoir si les gens lisent son portail), mais surtout l'expérience a 
montré que c'est absolument essentiel tant pour permettre certains scénarios 
de livraison de contenu locatif que pour permettre la gestion de l'espace 
portail).  Si c'est délégué au CMS, ça veut dire que chaque CMS doit recréer 
une quantité phénoménale de logique (ou sinon est limité au scénario .  Dans 
le cas où c'est délégué à wifidog, ça signifie des contraintes de latence 
élevée.  Une troisième voie serait de l'envoyer dans une bd distribuée (c'est 
le genre de job pour laquelle couchdb excelle)
- J'en oublie sûrement un paquet

Les réponses à ces différentes questions changent énormément la conception et 
le 'scope' de l'API, et l'architecture future de wifidog.  Coder maintenant 
sans statuer sur une bonne partie de ces question va probablement résulter en 
une grande quantité de code jetable, d'autant plus qu'il est évident qu'il n'y 
a même pas encore une compréhension mutuelle des problèmes à régler (c'est 
pour ça qu'on voulait commencer par les user stories...)

Ayant travaillé sur un certain nombre de standard ISO et IEEE, je peux vous 
dire que c'est seulement dans la mesure où un protocole n'est ni:
-sous-spécifié (trop vague et avec trop peu d'éléments obligatoire pour assurer 
une compatibilité plus grande que le plus petit dénominateur commun.) 
-sur-spécifié (demandant trop d'infrastructure et trop rigide pour avoir un 
grand nombre d'implantation indépendante)
Qu'un protocole peut-il soutenir l'ensemble de la vision pour lequel il a été 
conçu.

Certes, les standards évoluent, mais sans une basse solide, ils sont plutôt 
remplaçés.

Prenons donc le temps nécessaire. Pendant que les gens intéressés à ce travail 
un peu plus théorique s'y consacrent, il y a amplement d'autres défis auxquels 
se consacrer pour occuper les gens avide de concret:

Au niveau de la gestion des réseaux (traffic shaping dynamique, firmware, gestion 
centralisée, etc).  

Au niveau du contenu, pour l'instant presque tout ce qui est disponible en 
terme de contenu géolocalisé et réutilisable est dans des fils ATOM et RSS 
géotaggé et dans des fichiers iCal.  Ne pourrait-on pas, plutôt que de débattre 
du meilleur moyen d'aligner une image dans wifidog, terminer les agrégateurs 
location aware que l'on veut développer, quitte à faire recracher à wifidog des 
fils RSS pré-digéré après avec déterminé les entrées pertinentes pour le 
bénéfices des WordPress de ce monde?
 
> Les données sont dans Wifidog/Serveur, les plugins de WordPress (ou de
> Joomla ou de Drupal) les exploiteront, et je ne vois pas comment
> toutes les possibilités actuelles ne seraient pas supportées (par une
> approche différente certe, mais facilement plus conviviale!).

Pour de nombreuses raisons (dont certaines ont été évoquées plus haut).  Mais 
j'en suis arrivé à la conclusion que dans le monde réel (où il n'y a pas des 
centaines de développeurs qui vont se mettre au travail si on passe finalement 
à la technologie X ou si on tranche le débat Y) in ne sert pas à grand chose 
de s'y attarder pour l'instant.

La situation est simple:

La grande majorité des développeurs veulent utiliser des outils avec lesquels 
ils sont familiers (peu importe les raisons invoquées) et ces outils changent 
avec le temps:
Simplement pour illustrer, le projet wifidog a commencé:
- Un an après la sortie de wordpress
- La même année que la sortie de Django et Pylons et Ruby on rails et Google 
maps
- Un an avant la disponibilité publique de Facebook.

Il faut donner aux développeurs la possibilités d'utiliser leurs outils 
favoris maintenant (Scénario 1), à moyen terme (Scénario 2) puis à long terme 
(Standards ouverts génériques).

Je ne veux plus entendre parler du CMS de wifidog!   

- Il est, était, et restera pourri pour les scénarios ce que les gens semblent 
essayer de lui faire faire (créer du contenu simple et statique), mais que les 
développeurs n'ont jamais voulu s'occuper JUSTEMENT pour que les ressources de 
développement ne soient pas dilapidées à réinventer ce que des centaines de 
CMS essaient avec un succès hautement variable de rendre simple!
- Stocker du contenu dans le "CMS" de wifidog était un mal nécessaire parce 
qu'il n'y avait aucun contenu locatif disponible, et peu de système capable de 
gérer du contenu réellement multilingue.  Ce n'est plus le cas aujourd'hui.  
Le rôle du "CMS" de wifidog devrait donc se limiter à:
  - Implantation de référence pour les protocoles de wifidog
  - Stocker du contenu dont le scénario de livraison locatif exige des 
métadonnées qui ne sont gérées par aucun autre système existant.
  - Re-diffuser du contenu après un traitement locatif.

Un portail par hotspot est mieux que pas de contenu locatif du tout.  

Les gens se rendront compte à l'usage des limitations des systèmes actuels.  
Posez vous la question:  Si développer un gestionnaire convivial aggrégeant du 
contenu locatif était simple, ne pensez-vous pas qu'aujourd'hui (presque 5 ans 
plus tard) avec la popularité des iPhones de ce monde (et les millions de 
dollars dépensée pour écrire des applications) n'y aurait-il pas déjà de 
multiples solutions simples disponibles?

Fort de cette expérience la question pourra être revisitée à ce moment avec un 
peu plus d'objectivité de la part de chacun.  Avec un peu de chance, à ce 
monent on aura une norme inter-plate-forme pour les portlets et la gestion de 
contenu dans wifidog se résumera à offrir une série de portlets location-aware 
utilisés par des serveurs de portails comme liferay ou des CMS (problème bien 
assez complexe pour occuper des développeurs pendant longtemps).  

En fait cette issue est presque inévitable (à long terme).  La question est de 
savoir s'il les standards de-facto seront ouvert et contrôlés par la 
communauté ou s'il faudra passer par une longue période de produits 
propriétaire parce que notre communauté sera trop occuper à débattre quel 
outil est le plus ajaxweb2.0socialmashuptagblog et repartir constamment à zéro 
plutôt qu'à se concentrer créer ce qui n'existe pas actuellement et restera 
applicable dans le futur.

L'essentiel des problématiques et solutions potentielles avaient été bien 
identifiés à Londres en 2005 (World Summit on free Information 
Infrastructures).  Malgré les énormes changements qu'on connu le web depuis, 
il est presque incroyable à quel point nous avons peu avancé.  Pourtant on 
n'avait le gros de la technologie nécessaire en 2005 (mapserver, atom, une 
bonne part du wifidog actuel, des aggrégateur RSS multi-critères, PostGIS) et 
plus encore aujourd'hui aujourd'hui (JSON, les bases de données distribuées, 
les serveurs de portlets (enfin, presque...))

Alors SVP ramassons les fruits qui sont déjà tombé par terre plutôt que d'en 
faire de la compote en sautant dessus en essayant d'atteindre le fruit à la 
cime de l'arbre.

C'est d'autant plus essentiel que je ne pensais même pas que le WiFi serait 
encore quelque chose de significatif en 2010.  Il semble qu'il le restera 
encore pour un petit bout de temps, mais le moins que l'on puisse dire c'est 
qu'il n'est plus le centre de gravité des question de contenu locatif...

Si on ne trouve pas rapidement une direction commune (en se concentrant sur ce 
que nous avons réellement de commun), le train va continuer sans nous.

P.S.:  Merci à Alexis qui m'a permis de me remettre à rêver assez longtemps 
pour prendre le temps de trouver un chemin crédible pour avancer.  Il est 
vraiment temps que l'on ailles prendre une bière!
-- 
Benoit Grégoire


Plus d'informations sur la liste de diffusion WiFiDog