Là, on ne s'en détache pas, au contraire il y a manifestement des développements spécifiques pour s'y rattacher … Ou alors il faut expliquer en détail la stratégie de s'attacher pour pouvoir s'en détacher :)
Aucun développement spécifique n'a été fait pour se rattacher à Google et Facebook, ceux-ci implémentent certains bout de standards ce qui permet à Movim de se connecter à ces réseaux.
Moi, cette phrase ne me fais pas envie. Mon réflexe de développeur c'est de me dire "qu'est-ce qui me prouve que ça ne sera pas à nouveau entièrement réécrit dans 3 versions ?". Il y a peut-être une excellente raison, mais quand tu veut attirer des contributeurs, tu ne mets pas en avant les points bloquants. Surtout quand lesdits point bloquant ne sont absolument pas pertinents (parce que normalement, le nouveau contributeur n'est pas impacté par les refactoring passés …).
La réécriture a été dans le sens de la standardisation du code source. Movim respecte maintenant les normes de codages PHP (voir http://www.php-fig.org/) permettant de facilement intégrer des modules de la communauté et de standardiser la structure du cœur du projet. Donc l'idée ici n'est pas du tout de "tout casser" mais de faciliter l'entrée aux nouveaux développeurs en leurs offrant un environnement semblables aux autres CMS et Frameworks.
C'est bien d'être honnête, mais là ça ne donne absolument pas envie de s'impliquer. Là, en lisant, on comprends "il est tout seul". D'où une impression bizarre quand le texte parle "des" contributeurs par la suite. En plus, en en-tête de la section "Besoin de soutien", tu crée une impression qui sera conservée pour le reste de la section … Et donc qui à mon avis ruine l'efficacité de cette section (surtout qu'il y a d'autres moyens d'être honnête sans trop décourager les gens).
Sur ce point oui je préfère jouer l'honnêteté, les "contributeurs" sont majoritairement ma copine et quelques autres amis qui m'aident sur certains autres points délicats. Je comprend que la tourne peut porter confusion (ou du moins fausser le sentiment que j'ai voulu partager dans cette dépêche) mais je préfère montrer directement que le nombre de personnes qui touchent au projet peuvent se compter sur les doigts d'une main (comme de très nombreux projets open-sources en fait).
L'authentification sur XMPP passe par la norme SASL2 que Movim implémente. Je ne me souvient plus exactement quel niveau de chiffrement Google propose mais Movim ne fait que l'intermédiaire et ne stocke pas le mot de passe dans la base de donnée suite à l'authentification.
Saches aussi que Google est en train de supprimer le support XMPP de Gmail, donc d'ici quelques moi cette possibilité ne fonctionnera plus.
Pour le moment le chat est malheureusement limité à cette taille, la prochaine version va intégrer un nouveau système de messagerie en pleine page qui permettra de rendre tout ça plus confortable.
Movim implémente Message Carbons, donc vous pouvez sans soucis avoir un autre client XMPP ouvert et l'utiliser pour la partie Chat, les discussions seront synchronisées entre les différentes clients (il faut que le serveur XMPP l'implémente par contre).
Ici l'unicité est surtout sur le coté technique (le fait de marier PHP et XMPP) ;)
J'attends aussi beaucoup du projet Salut à Toi surtout pour la partie Microblogging, voir si j'ai pas fait de bétises dans mon implémentation. :)
Es ce que l'on peut avoir son propre serveur, se connecter sur un serveur d'un pote? Ou bien doit t'on avoir un compte obligatoire sur un "pod"?
À toi de choisir, si tu as un compte XMPP tu peux te connecter sur le serveur que tu souhaite, qu'il soit public, chez un pote ou chez toi :)
Si j'ai mon propre serveur, es ce que celui ci peut communiquer avec d'autre pour naviguer facilement sur les pages de mes amis qui n'ont pas de compte sur mon serveur?
Oui et c'est tout l'intérêt, ici tous les pods sont reliés entre eux via le réseau XMPP, chaque Pod n'est qu'une "fenêtre" sur le réseau.
Es ce que des personnes qui n'y connaissent rien en technique, peuvent facilement avoir un compte et profiter de ce réseau social?
https://movim.eu/node/374 tout en bas de la page, il faut se créer un compte XMPP/Jabber (ou utiliser son compte existant, attention, certains comptes n'ont pas toutes les fonctionnalités requise, Movim fonctionnera donc en mode "dégradé") et rejoindre un des Pods.
Vous pouvez aussi utiliser ce compte sur tous les autres clients XMPP (si Movim ne vous plait pas) : Empathy, Jappix, SàT, Pidgin…
Si le serveur sur lequel je suis décide de mettre la clé sous la porte inopinément, es ce que mes données peuvent être retrouver?
Si c'est le Pod Movim, normalement tu ne perd rien (sauf les images envoyés sur le serveur Web), il faut juste se reconnecter avec le même compte sur un autre Pod. Tu as aussi la possibilité de clearer certaines des informations de la base de donnée depuis Movim avant de partir.
Y a t'il une page où sont listés les modules existant? Suis je dépendant du serveur pour le choix des modules que je peux installer?
Les modules sont essentiellement là pour le développement et ne peuvent pas (encore) être personnalisés par l'utilisateur. Donc pour le moment tous les serveurs ont les mêmes modules (sauf si l'admin a volontairement changé le code source :)).
En tout cas, le projet est intéressant. J'aime bien la fonction de blog + réseau social. Si j'ai bien tout compris, cela permet de créer une vrai page web tout en la partageant avec des amis facilement.
Oui on a ajouté un mode pour "sortir" les données du réseau et générer une page HTML statique qu'on peut partager avec tout le monde (https://pod.movim.eu/?q=blog&f=edhelas@movim.eu&n=urn:xmpp:microblog:0#blog pour ma page). Un flux Atom est aussi généré pour ceux qui souhaiteraient s'abonner au flux public d'un compte Movim.
Et pourtant, des fois il faut un peu sortir des protocoles "classiques" (POP, IMAP, SMTP) et regarder autour.
XMPP offre dans sa norme depuis de nombreuses années des possibilités similaires à l'email (répondre, mailing-list, pièces jointes, copie cachée…) le tout sur un protocole moderne, vachement extensible, avec une vraie gestion de la liste de contact, des présences, des vCards, de la sécurité…
Je rêve de voir l'implémentation de ces fonctionnalités dans Thunderbird de façon à les intégrer proprement à l'interface. Le bug existe depuis 2007 (https://bugzilla.mozilla.org/show_bug.cgi?id=385758) et n'a pas avancé d'un poil (enfin si ils ont ajouté la fonction "chat" mais bon…, ça sert pas à grand chose).
Si Mozilla a révolutionné les standards Web à l'époque d'IE6, il peut également le faire avec la messagerie. Sortir une nouvelle version de Thunderbird avec un support complet de XMPP ce serait montrer que Mozilla a les c**** d'aller de l'avant dans un monde où les clients de messagerie ne bougent presque plus depuis 10 ans. Ce serait une petite révolution pour les particuliers et les entreprises (la plupart des serveurs XMPP peuvent se connecter aux LDAP).
On voit fleurir depuis quelques temps des dizaines de clients de messagerie (Viber, WhatsApp, BBM…) et pourtant le mail reste un peu le truc "old school" qu'on laisse de coté.
Je compte implémenter toutes ces fonctionnalités dans mon projet (http://movim.eu/) pour la prochaine version sous la forme d'un "webmail" mais le tout se basant uniquement sur les possibilités de XMPP.
Mozilla, ne laisses pas mourrir Thunderbird, il y a tellement de choses à faire !
Oui pourquoi :) ?
Je dirait surtout qu'on travaille sur le même protocole et offrir le choix aux utilisateurs d'avoir plusieurs clients pour accéder à leur compte est un gros plus. Après il est sur que le fait de travailler sur des projets distincts à tendance à diluer les efforts qui pourraient êtres fait :(
Le cas du temps réel avec du flux RSS/Atom est (presque) possible. Je travaille depuis un petit bout de temps sur un projet de réseau social XMPP (http://movim.eu/) et la dernière version contient déjà un système permettant de lire des flux d'actualité PubSub (publish-subscribe) le tout lié à la puissance d'XMPP (temps réel, facilité d'implémentation, standard…).
Je me suis débrouillé pour développer deux petits outils, l'un "normalise" tout les flux RSS en Atom, faut dire que le RSS est une vraie horreur là où Atom apporte une norme simple et facile à comprendre (et donc à parser), https://code.launchpad.net/~edhelas/+junk/feedcleaner. Le second parse ces flux Atom pour les injecter sur des nœuds Pubsub. Les utilisateurs de Jabber/XMPP n'auront plus qu'à s'y abonner et recevoir leurs actu en temps réel sur Movim, https://code.launchpad.net/~edhelas/+junk/atomtopubsub :)
Le tout est standard, implémentable partout et ça permet d'avoir le meilleur des deux mondes.
Et tout ça est responsive design, donc passe nickel sur mobile :)
Je corrige une petite bétise, la 1.0 n'est pas prévue à la fin de l'année.
Les releases se font sur un rythme de 6 mois en 0.x. La 1.0 sortira quand elle sera prête (Debian staÿle) et sera peut être une 0.9, 0.10 ou plus :)
Ça fait 5 ans que je bosse sur un projet de réseau social utilisant le protocole XMPP (http://movim.eu/) et l'argument "Google" était important pour nous (avoir plusieurs millions de contacts ajoutables). Cette décision va pas mal nous porter atteinte.
Ce genre de décision peut passer, encore aujourd'hui, sans trop de soucis. Mais imaginer qu'ils décident de n'autoriser l'envois d'email qu'entre comptes Gmail, c'est un peu le même soucis de ce coté.
Malgré ses défauts (et il y en a) XMPP est encore aujourd'hui LE protocole qui permet de fédérer une grosse partie des échanges, il est disponible un peu partout et est facilement "bidouillable". Notre projet offre déjà de nombreuses fonctionnalités utilisant uniquement XMPP (chat, liste de contact, invitation, partage de médias, groupes, géolocalisation, "écoute en cours"…), nous comptons travailler sur l'intégration de la visio-conférence cet été (en standard, dans le navigateur via HTML5/WebRTC).
Cette décision montre encore que les "grands" du Web continuent à tirer la couverture chacun de leurs coté et qu'il y a encore beaucoups de boulot à faire pour standardiser et mettre tout le monde d'accord.
Personnellement, je pense que cette décision va signer la fin définitive de mon compte Gmail, je vais me démerder pour héberger tout ça chez moi dès cet été.
Le paquet était fait pour les dernières versions de Ubuntu il est impossible de l'installer sans tout péter sur Debian :D. Y'a des courageux qui ont réussit (Debian Wheezy i386) ?
Pour le partage de documents il existe deux façon de faire, soit tu fait un espèce de P2P entre les deux clients, soit tu balance ça sur un serveur et tu file une url (plus simple à implémenter), la première est standardisé l'autre c'est juste un hack :)
Et pour la recherche dans les archives, coté XMPP tu as une limite de temps (3mois d'historique en moyenne), pour Movim ce sera dans un bête BDD (avec là aussi une limite de temps).
C'est une contrainte essentiellement technique, nous utilisons Curl pour interroger le serveur XMPP via Bosh car PHP est difficilement "démonisable" je veux dire par là qu'on ne peut pas interagir avec lui comme un simple processus.
On maintient donc la connexion via des requètes Curl HTTP "long polling" (le serveur ne nous répond pas tant qu'il n'a pas quelque chose à dire). Et l'interrogation d'un serveur XMPP de cette façon passe obligatoirement par son interface BOSH.
Il faut aussi savoir que l'on peut utiliser un serveur BOSH seul (comme Punjab) qui permet alors de se connecter à n'importe quel serveur XMPP derrière. Ce que j'ai fait sur ma machine, Movim interrogeant Punjab en localhost :)
Movim utilise une architecture dite "client léger", tout les traitements (notamment la connexion, le système de cache, la session) se fait du coté du serveur web, sur Jappix l'architecture est "client lourd" tout se fait via le navigateur en Javascript ;)
Par contre Jappix et nous implémentons XMPP strictement depuis la norme définie, donc nous sommes déjà totalement compatibles (envois d'un messages, liste de contact...).
@JoeltheLion
Notre but pour l'instant est d'implémenter les fonctionnalités sociales présentes dans XMPP dans l'interface d'un réseau social (flux d'actualité, commentaires, carte d'identité) mais nous avons prévu l'interface modulaire pour ne pas contraindre l'utilisateur à faire comme "tout les autres" il choisira les modules qu'il souhaite mettre en place :). Dans les prochaines versions nous allons surtout nous concentrer sur le module "Chat" (liste de contact, présences, messages perso, salons de discussion), le "Mur" (flux d'actualité, commentaires) et le Profil.
@Nicolas Boulay
Tu dois parler du fameux "social graph" de Facebook, je ne pense pas qu'une technologie de ce genre soit forcément bonne pour le respect de la vie privé si le "graph" est centralisé. Dans notre cas on pourrait imaginer en effet l'ajout de petits boutons "commenter" ou autres qui permettrait de mettre à jour notre statut sur ce qu'on trouve ici et là sur le net. Mais je pense qu'une importante réflexion est ici nécessaire pour ne pas sombrer dans un "Facebook-like" où le flux d'actualité de la personne devienne un simple point central de son activité sur internet.
@ptifeth
Les difficultés rencontrées sont en majeure partie liées au protocole XMPP, en effet nous sommes presque les premiers (Jappix est sur le même chemin) à implémenter certaines extensions de ce protocole, extensions (appelées XEP) qui sont pour certaines pas encore présente sur une majorité de serveurs XMPP (je pense en particulier à PubSub). De plus fabriquer une application qui fonctionne en temps réel sur une technologie (PHP) qui est à la base développée pour avoir une exécution linéaire est un petit défi pour nous :).
La bibliothèque de gestion de sessions n'est pas compliquée en elle même nous avons simplement déporté le gestion des variables par un SGBD (actuellement Sqlite mais nous travaillons à la mise en place d'une interface qui va permettre de mettre à peu près n'importe quoi en dessous ;)).
Le choix de PHP est déjà un choix stratégique, il est déjà largement déployé sur les serveurs Web et nous avons aussi pas mal de connaissances sur cette technologie :)
[^] # Re: Authentification
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim: Appel à soutien. Évalué à 4.
La réécriture a été dans le sens de la standardisation du code source. Movim respecte maintenant les normes de codages PHP (voir http://www.php-fig.org/) permettant de facilement intégrer des modules de la communauté et de standardiser la structure du cœur du projet. Donc l'idée ici n'est pas du tout de "tout casser" mais de faciliter l'entrée aux nouveaux développeurs en leurs offrant un environnement semblables aux autres CMS et Frameworks.
Sur ce point oui je préfère jouer l'honnêteté, les "contributeurs" sont majoritairement ma copine et quelques autres amis qui m'aident sur certains autres points délicats. Je comprend que la tourne peut porter confusion (ou du moins fausser le sentiment que j'ai voulu partager dans cette dépêche) mais je préfère montrer directement que le nombre de personnes qui touchent au projet peuvent se compter sur les doigts d'une main (comme de très nombreux projets open-sources en fait).
[^] # Re: Authentification
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim: Appel à soutien. Évalué à 2.
L'authentification sur XMPP passe par la norme SASL2 que Movim implémente. Je ne me souvient plus exactement quel niveau de chiffrement Google propose mais Movim ne fait que l'intermédiaire et ne stocke pas le mot de passe dans la base de donnée suite à l'authentification.
Saches aussi que Google est en train de supprimer le support XMPP de Gmail, donc d'ici quelques moi cette possibilité ne fonctionnera plus.
[^] # Re: Tout piti wini rikiki
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim: Appel à soutien. Évalué à 4.
Pour le moment le chat est malheureusement limité à cette taille, la prochaine version va intégrer un nouveau système de messagerie en pleine page qui permettra de rendre tout ça plus confortable.
Movim implémente Message Carbons, donc vous pouvez sans soucis avoir un autre client XMPP ouvert et l'utiliser pour la partie Chat, les discussions seront synchronisées entre les différentes clients (il faut que le serveur XMPP l'implémente par contre).
[^] # Re: Unique en son genre
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim: Appel à soutien. Évalué à 4.
Ici l'unicité est surtout sur le coté technique (le fait de marier PHP et XMPP) ;)
J'attends aussi beaucoup du projet Salut à Toi surtout pour la partie Microblogging, voir si j'ai pas fait de bétises dans mon implémentation. :)
[^] # Re: Movim saikoi
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim: Appel à soutien. Évalué à 7.
À toi de choisir, si tu as un compte XMPP tu peux te connecter sur le serveur que tu souhaite, qu'il soit public, chez un pote ou chez toi :)
Oui et c'est tout l'intérêt, ici tous les pods sont reliés entre eux via le réseau XMPP, chaque Pod n'est qu'une "fenêtre" sur le réseau.
https://movim.eu/node/374 tout en bas de la page, il faut se créer un compte XMPP/Jabber (ou utiliser son compte existant, attention, certains comptes n'ont pas toutes les fonctionnalités requise, Movim fonctionnera donc en mode "dégradé") et rejoindre un des Pods.
Vous pouvez aussi utiliser ce compte sur tous les autres clients XMPP (si Movim ne vous plait pas) : Empathy, Jappix, SàT, Pidgin…
Si c'est le Pod Movim, normalement tu ne perd rien (sauf les images envoyés sur le serveur Web), il faut juste se reconnecter avec le même compte sur un autre Pod. Tu as aussi la possibilité de clearer certaines des informations de la base de donnée depuis Movim avant de partir.
Les modules sont essentiellement là pour le développement et ne peuvent pas (encore) être personnalisés par l'utilisateur. Donc pour le moment tous les serveurs ont les mêmes modules (sauf si l'admin a volontairement changé le code source :)).
Oui on a ajouté un mode pour "sortir" les données du réseau et générer une page HTML statique qu'on peut partager avec tout le monde (https://pod.movim.eu/?q=blog&f=edhelas@movim.eu&n=urn:xmpp:microblog:0#blog pour ma page). Un flux Atom est aussi généré pour ceux qui souhaiteraient s'abonner au flux public d'un compte Movim.
[^] # Re: webmail
Posté par edhelas (site web personnel) . En réponse au journal Thunderbird : j'en peux plus ! Qui arrive à l'utiliser pour de vrai ? Quoi d'autre ?. Évalué à 10.
Et pourtant, des fois il faut un peu sortir des protocoles "classiques" (POP, IMAP, SMTP) et regarder autour.
XMPP offre dans sa norme depuis de nombreuses années des possibilités similaires à l'email (répondre, mailing-list, pièces jointes, copie cachée…) le tout sur un protocole moderne, vachement extensible, avec une vraie gestion de la liste de contact, des présences, des vCards, de la sécurité…
Je rêve de voir l'implémentation de ces fonctionnalités dans Thunderbird de façon à les intégrer proprement à l'interface. Le bug existe depuis 2007 (https://bugzilla.mozilla.org/show_bug.cgi?id=385758) et n'a pas avancé d'un poil (enfin si ils ont ajouté la fonction "chat" mais bon…, ça sert pas à grand chose).
Si Mozilla a révolutionné les standards Web à l'époque d'IE6, il peut également le faire avec la messagerie. Sortir une nouvelle version de Thunderbird avec un support complet de XMPP ce serait montrer que Mozilla a les c**** d'aller de l'avant dans un monde où les clients de messagerie ne bougent presque plus depuis 10 ans. Ce serait une petite révolution pour les particuliers et les entreprises (la plupart des serveurs XMPP peuvent se connecter aux LDAP).
On voit fleurir depuis quelques temps des dizaines de clients de messagerie (Viber, WhatsApp, BBM…) et pourtant le mail reste un peu le truc "old school" qu'on laisse de coté.
Je compte implémenter toutes ces fonctionnalités dans mon projet (http://movim.eu/) pour la prochaine version sous la forme d'un "webmail" mais le tout se basant uniquement sur les possibilités de XMPP.
Mozilla, ne laisses pas mourrir Thunderbird, il y a tellement de choses à faire !
[^] # Re: Et pourquoi ?
Posté par edhelas (site web personnel) . En réponse à la dépêche Salut à Toi 0.4.0: toujours en chemin.... Évalué à 2.
Oui pourquoi :) ?
Je dirait surtout qu'on travaille sur le même protocole et offrir le choix aux utilisateurs d'avoir plusieurs clients pour accéder à leur compte est un gros plus. Après il est sur que le fait de travailler sur des projets distincts à tendance à diluer les efforts qui pourraient êtres fait :(
[^] # Et pourquoi pas lier RSS/Atom et réseau social ?
Posté par edhelas (site web personnel) . En réponse au journal Twitter vs RSS/ATOM pour suivre un site. Évalué à 7. Dernière modification le 21 février 2014 à 08:36.
Le cas du temps réel avec du flux RSS/Atom est (presque) possible. Je travaille depuis un petit bout de temps sur un projet de réseau social XMPP (http://movim.eu/) et la dernière version contient déjà un système permettant de lire des flux d'actualité PubSub (publish-subscribe) le tout lié à la puissance d'XMPP (temps réel, facilité d'implémentation, standard…).
Je me suis débrouillé pour développer deux petits outils, l'un "normalise" tout les flux RSS en Atom, faut dire que le RSS est une vraie horreur là où Atom apporte une norme simple et facile à comprendre (et donc à parser), https://code.launchpad.net/~edhelas/+junk/feedcleaner. Le second parse ces flux Atom pour les injecter sur des nœuds Pubsub. Les utilisateurs de Jabber/XMPP n'auront plus qu'à s'y abonner et recevoir leurs actu en temps réel sur Movim, https://code.launchpad.net/~edhelas/+junk/atomtopubsub :)
Le tout est standard, implémentable partout et ça permet d'avoir le meilleur des deux mondes.
Et tout ça est responsive design, donc passe nickel sur mobile :)
[^] # Re: Movim
Posté par edhelas (site web personnel) . En réponse au journal Identi.ca est mort, vivie identi.ca ? / Movim 0.7. Évalué à 2.
Je corrige une petite bétise, la 1.0 n'est pas prévue à la fin de l'année.
Les releases se font sur un rythme de 6 mois en 0.x. La 1.0 sortira quand elle sera prête (Debian staÿle) et sera peut être une 0.9, 0.10 ou plus :)
# Fu** you Google
Posté par edhelas (site web personnel) . En réponse au journal Google Hangouts remplace Talk: la fin de la fédération XMPP ?. Évalué à 10.
Ça fait 5 ans que je bosse sur un projet de réseau social utilisant le protocole XMPP (http://movim.eu/) et l'argument "Google" était important pour nous (avoir plusieurs millions de contacts ajoutables). Cette décision va pas mal nous porter atteinte.
Ce genre de décision peut passer, encore aujourd'hui, sans trop de soucis. Mais imaginer qu'ils décident de n'autoriser l'envois d'email qu'entre comptes Gmail, c'est un peu le même soucis de ce coté.
Malgré ses défauts (et il y en a) XMPP est encore aujourd'hui LE protocole qui permet de fédérer une grosse partie des échanges, il est disponible un peu partout et est facilement "bidouillable". Notre projet offre déjà de nombreuses fonctionnalités utilisant uniquement XMPP (chat, liste de contact, invitation, partage de médias, groupes, géolocalisation, "écoute en cours"…), nous comptons travailler sur l'intégration de la visio-conférence cet été (en standard, dans le navigateur via HTML5/WebRTC).
Cette décision montre encore que les "grands" du Web continuent à tirer la couverture chacun de leurs coté et qu'il y a encore beaucoups de boulot à faire pour standardiser et mettre tout le monde d'accord.
Personnellement, je pense que cette décision va signer la fin définitive de mon compte Gmail, je vais me démerder pour héberger tout ça chez moi dès cet été.
edhelas
# Et sur Debian ?
Posté par edhelas (site web personnel) . En réponse au journal Steam sur Linux disponible au téléchargement. Évalué à 2.
Le paquet était fait pour les dernières versions de Ubuntu il est impossible de l'installer sans tout péter sur Debian :D. Y'a des courageux qui ont réussit (Debian Wheezy i386) ?
[^] # Re: bosh?
Posté par edhelas (site web personnel) . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 6. Dernière modification le 02 juillet 2012 à 17:45.
Pour le partage de documents il existe deux façon de faire, soit tu fait un espèce de P2P entre les deux clients, soit tu balance ça sur un serveur et tu file une url (plus simple à implémenter), la première est standardisé l'autre c'est juste un hack :)
La gestion des droits est très fine dans XMPP sur les fluxs Pubsub, je t'invite à lire la XEP 0060 pour constater ça http://xmpp.org/extensions/xep-0060.html#affiliations
Et pour la recherche dans les archives, coté XMPP tu as une limite de temps (3mois d'historique en moyenne), pour Movim ce sera dans un bête BDD (avec là aussi une limite de temps).
[^] # Re: bosh?
Posté par edhelas (site web personnel) . En réponse à la dépêche Et voici Movim 0.5 « Snowball » !. Évalué à 3.
C'est une contrainte essentiellement technique, nous utilisons Curl pour interroger le serveur XMPP via Bosh car PHP est difficilement "démonisable" je veux dire par là qu'on ne peut pas interagir avec lui comme un simple processus.
On maintient donc la connexion via des requètes Curl HTTP "long polling" (le serveur ne nous répond pas tant qu'il n'a pas quelque chose à dire). Et l'interrogation d'un serveur XMPP de cette façon passe obligatoirement par son interface BOSH.
Il faut aussi savoir que l'on peut utiliser un serveur BOSH seul (comme Punjab) qui permet alors de se connecter à n'importe quel serveur XMPP derrière. Ce que j'ai fait sur ma machine, Movim interrogeant Punjab en localhost :)
[^] # Re: Quelques réponses aux interrogations
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim, sortie de la version 0.2. Évalué à 3.
Movim utilise une architecture dite "client léger", tout les traitements (notamment la connexion, le système de cache, la session) se fait du coté du serveur web, sur Jappix l'architecture est "client lourd" tout se fait via le navigateur en Javascript ;)
Par contre Jappix et nous implémentons XMPP strictement depuis la norme définie, donc nous sommes déjà totalement compatibles (envois d'un messages, liste de contact...).
[^] # Re: login ?
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim, sortie de la version 0.2. Évalué à 3.
Le compte de test est "contact@movim.eu" j'ai mis à jour la doc ;)
# Quelques réponses aux interrogations
Posté par edhelas (site web personnel) . En réponse à la dépêche Movim, sortie de la version 0.2. Évalué à 9.
@JoeltheLion
Notre but pour l'instant est d'implémenter les fonctionnalités sociales présentes dans XMPP dans l'interface d'un réseau social (flux d'actualité, commentaires, carte d'identité) mais nous avons prévu l'interface modulaire pour ne pas contraindre l'utilisateur à faire comme "tout les autres" il choisira les modules qu'il souhaite mettre en place :). Dans les prochaines versions nous allons surtout nous concentrer sur le module "Chat" (liste de contact, présences, messages perso, salons de discussion), le "Mur" (flux d'actualité, commentaires) et le Profil.
@Nicolas Boulay
Tu dois parler du fameux "social graph" de Facebook, je ne pense pas qu'une technologie de ce genre soit forcément bonne pour le respect de la vie privé si le "graph" est centralisé. Dans notre cas on pourrait imaginer en effet l'ajout de petits boutons "commenter" ou autres qui permettrait de mettre à jour notre statut sur ce qu'on trouve ici et là sur le net. Mais je pense qu'une importante réflexion est ici nécessaire pour ne pas sombrer dans un "Facebook-like" où le flux d'actualité de la personne devienne un simple point central de son activité sur internet.
@ptifeth
Les difficultés rencontrées sont en majeure partie liées au protocole XMPP, en effet nous sommes presque les premiers (Jappix est sur le même chemin) à implémenter certaines extensions de ce protocole, extensions (appelées XEP) qui sont pour certaines pas encore présente sur une majorité de serveurs XMPP (je pense en particulier à PubSub). De plus fabriquer une application qui fonctionne en temps réel sur une technologie (PHP) qui est à la base développée pour avoir une exécution linéaire est un petit défi pour nous :).
La bibliothèque de gestion de sessions n'est pas compliquée en elle même nous avons simplement déporté le gestion des variables par un SGBD (actuellement Sqlite mais nous travaillons à la mise en place d'une interface qui va permettre de mettre à peu près n'importe quoi en dessous ;)).
Le choix de PHP est déjà un choix stratégique, il est déjà largement déployé sur les serveurs Web et nous avons aussi pas mal de connaissances sur cette technologie :)
En espérant avoir répondu à vos interrogations ;)
edhelas