[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