Communauté Elgg francophone

Créer un compteAide  
Connexion
Réseau d'Elgg acentré
Ce groupe réunit les personnes intéressées par le développement de fonctionnalités "P2P" de Elgg

Une roadmap pour les réseaux acentrés avec Elgg ?

Bonjour,

cette idée de réseaux d'Elgg est lancée depuis un bout de temps, mais sans avancer... Non décidé

Il me semble que c'est le déclencheur du mouvement qui fait défaut car tout est là : les formats et protocoles de données d'échange, les idées, les personnes aptes à le développer.. Bref, qu'attendons-nous ?

Sans doute une définition du projet plus précise dans un premier temps : acentré oui, mais comment ?

  1. est-ce qu'il s'agit de quelque chose qui serait mis en place par les admins/dévs de sites basés sur Elgg ?
    1. via un plugin générique ?
      1. avec des liaisons déclarées par les admins du site ?
      2. ou choisies par les utilisateurs qui gèrent eux-même leurs connexions entre sites ?
        1. à partir d'objets (users, groups, objects) identiques ?
        2. ou via leurs propres mappings de données ?
    2. ou via une implémentation spécifique par les dévs du site ?
  2. ou quelque chose qui serait géré par les utilisateurs ?
    1. nécessitant une mise en place par les dévs/admins d'un site Elgg ?
    2. ou générique ?
  3. ...

..well..

quelques idées en vrac seulement, on peut trouver bien d'autres manières de définir ce qu'est un réseau acentré concrètement  ;)

difficile sans commande ou besoin précis, autre que pour l'exercice de style, de se lancer dans quelque chose de concret !

Donc commençons par savoir ce qu'on veut exactement, pour ne pas faire quelque chose d'inutile ou qui se retrouve au final inutilisable car pas réaliste : je veux dire que si on pense compter sur le fait que les admins de sites mettent tous en place un plugin et activent un plugin indispensable au fonctionnement du système, il ne faudra pas s'étonner que de nombreux sites ne le fassent pas, pour plein de raisons.

Donc est-ce qu'on veut pouvoir fonctionner en réseau de sites de confiance, et avec quel niveau d'adhésion des responsables de sites ? => selon qu'il suffisent d'installer, voire configurer un plugin, ou utiliser un plugin de base pour faire une implémentation complète, ça n'aura clairement pas la même facilité de mise en place et donc sans doute de succès permettant à ce type de connexions de se développer.

 

Scénario d'usage donc pour commencer à engager le sujet ; j'hésiterais donc entre premières hypothèses :

  • soit une fonctionnalité assez standard et facile à mettre en place via un plugin très générique, configurable à la guise de l'utilisateur, mais avec peut-être une configuration mininale par l'admin, du genre définir ce qu'on peut échanger comme données, et si par exemple on autorise des accès entrants en édition de contenu..   ~ Là on accède relativement aisément à ses données et on imagine la possibilité de mettre en place son propre serveur pour récupérer les données éparpillées.
  • soit ce qui ressemblerait plutôt à un réseau de sites de confiance, susceptibles par défaut d'aller plus loin dans l'interconnexion (avec peut-être plus naturellement des possibilités d'édition ou de push de données)   ~ mais qui a priori seraient moins ouverts à la possibilité d'accéder à ses données depuis le site de son choix (disposant du plugin nécessaire, que ce soit le sien ou celui d'un service tiers) .

Si on veut permettre à tout un chacun d'avoir une possibilité d'accès externe libre à ses données, on partirait sur la première hypothèse : dans ce cas, il faudrait faire en sorte que le coût (pas financier, global) de mise en place soit aussi faible que possible si l'on veut espérer que les sites le mettent en place - parce qu'un outil qui peut être considéré comme un aspirateur de contenus, ça ne va pas forcément faire rêver tous les types de sites, et pour que ça ait du sens, il faudrait que ce soient précisément sur les sites qui ne font pas partie du propre cercle de confiance de l'utilisateur qu'on devrait mettre en place ce genre de foncitonnalités.

En gros, les sites relativement ouverts l'utiliseront, et tant mieux, mais pas forcément d'autres sites qui n'y auront pas forcément intérêt.. On peut les en convaincre, mais là on entre dans l'hypothétique.

 

Bref, commençons par cette discussion de définition de ce qu'on attend, en se donnant comme limite qu'on développe ici sur Elgg, donc côté serveur, mais pas sur un outil tiers du genre client tierce partie qui devrait aller y piocher des données (juste parce qu'il s'agit d'un autre projet).

 

Dernière remarque : j'aimerais qu'on se fixe des choses très rapides à mettre en place, et qu'on avance non pas en construisant un grand projet, mais plutôt par petites touches immédiatement utilisables/montrables, par exemple :

  1. une première base de plugins implémentant OAuth ou autre choix de techno pour diverses versions d'Elgg - la dernière version étant loin d'être encore utilisée par tout le monde ici (et même si OAuth semble déjà implémenté -ai pas encore testé-, il faudra de toutes façons discuter entre sites de diverses versions, et puis le plugin OAuth pour la 1.6 et la 1.7 est déjà tout à fait fonctionnel -ai testé en 1.6, OK-)    ~ à ce niveau on sait déjà connecter des sites entre eux - même si ça reste virtuel
  2. puis en ajoutant des accès aux données : données du profil sans doute pour commencer, en sachant que les profils sont généralement différents selon les sites
  3. ensuite voir comment on gère les données en tant qu'objets : voir si on s'appuie par exemple sur les UUID au lieu des GUID pour identifier les objets, et si on doit inclure des vues de définition ou de rendu des objets   - même si on reste encore en lecture seule, voir comment afficher un article de blog depuis un site qui n'utilise pas de blog - ça se résout facilement, mais de diverses manières selon ce qu'on veut..
  4. après on passe peut-être à choses comme du stockage en local de données externes    -  mais on peut aussi le faire en 2e si on considère que l'accès aux données est plus urgent que la possibilité d'en avoir un rendu fidèle  -  car on a quand même souvent des objets un peu particuliers ou spécifiques à chaque site, et on ne va pas balancer un paquet de métadonnées et relations attachés aux objets sans les normaliser..  mais bon, ça peut être un point de départ intéressant

il me semble qu'il faudrait commencer doucement, quitte à implémenter des standards d'échange progressivement, des intégrations de contenus tiers "exotiques" (objets qu'on ne rencontre pas forcément sur d'autres sites), ma fourniture de moyens de mapping ou de feuilles de définition des objets (d'ailleurs plus normalisé à paetir de la 1.8)    - en les ayant à l'esprit dès le départ bien sûr, mais sans se les imposer trop tôt, histoire d'avoir des choses suffisament fonctionnelles et montrables avant de passer trop de temps sur une usine à gaz.

 

J'espère que ces petits éléments de réflexion au fil de l'eau va permettre de se remotiver sur ce projet intéressant, qui n'attend que d'avoir des contours plus précis pour démarrer.

 

Je vous propose donc de poursuivre cette discussion ici même, puis que nous entamions un cahier des charges sur le wiki ("pages")

 

Réponses

  • Florian DANIEL ~ Facyla le 28 octobre 2011

    Bonjour,

    cette idée de réseaux d'Elgg est lancée depuis un bout de temps, mais sans avancer... Non décidé

    Il me semble que c'est le déclencheur du mouvement qui fait défaut car tout est là : les formats et protocoles de données d'échange, les idées, les personnes aptes à le développer.. Bref, qu'attendons-nous ?

    Sans doute une définition du projet plus précise dans un premier temps : acentré oui, mais comment ?

    1. est-ce qu'il s'agit de quelque chose qui serait mis en place par les admins/dévs de sites basés sur Elgg ?
      1. via un plugin générique ?
        1. avec des liaisons déclarées par les admins du site ?
        2. ou choisies par les utilisateurs qui gèrent eux-même leurs connexions entre sites ?
          1. à partir d'objets (users, groups, objects) identiques ?
          2. ou via leurs propres mappings de données ?
      2. ou via une implémentation spécifique par les dévs du site ?
    2. ou quelque chose qui serait géré par les utilisateurs ?
      1. nécessitant une mise en place par les dévs/admins d'un site Elgg ?
      2. ou générique ?
    3. ...

    ..well..

    quelques idées en vrac seulement, on peut trouver bien d'autres manières de définir ce qu'est un réseau acentré concrètement  ;)

    difficile sans commande ou besoin précis, autre que pour l'exercice de style, de se lancer dans quelque chose de concret !

    Donc commençons par savoir ce qu'on veut exactement, pour ne pas faire quelque chose d'inutile ou qui se retrouve au final inutilisable car pas réaliste : je veux dire que si on pense compter sur le fait que les admins de sites mettent tous en place un plugin et activent un plugin indispensable au fonctionnement du système, il ne faudra pas s'étonner que de nombreux sites ne le fassent pas, pour plein de raisons.

    Donc est-ce qu'on veut pouvoir fonctionner en réseau de sites de confiance, et avec quel niveau d'adhésion des responsables de sites ? => selon qu'il suffisent d'installer, voire configurer un plugin, ou utiliser un plugin de base pour faire une implémentation complète, ça n'aura clairement pas la même facilité de mise en place et donc sans doute de succès permettant à ce type de connexions de se développer.

     

    Scénario d'usage donc pour commencer à engager le sujet ; j'hésiterais donc entre premières hypothèses :

    • soit une fonctionnalité assez standard et facile à mettre en place via un plugin très générique, configurable à la guise de l'utilisateur, mais avec peut-être une configuration mininale par l'admin, du genre définir ce qu'on peut échanger comme données, et si par exemple on autorise des accès entrants en édition de contenu..   ~ Là on accède relativement aisément à ses données et on imagine la possibilité de mettre en place son propre serveur pour récupérer les données éparpillées.
    • soit ce qui ressemblerait plutôt à un réseau de sites de confiance, susceptibles par défaut d'aller plus loin dans l'interconnexion (avec peut-être plus naturellement des possibilités d'édition ou de push de données)   ~ mais qui a priori seraient moins ouverts à la possibilité d'accéder à ses données depuis le site de son choix (disposant du plugin nécessaire, que ce soit le sien ou celui d'un service tiers) .

    Si on veut permettre à tout un chacun d'avoir une possibilité d'accès externe libre à ses données, on partirait sur la première hypothèse : dans ce cas, il faudrait faire en sorte que le coût (pas financier, global) de mise en place soit aussi faible que possible si l'on veut espérer que les sites le mettent en place - parce qu'un outil qui peut être considéré comme un aspirateur de contenus, ça ne va pas forcément faire rêver tous les types de sites, et pour que ça ait du sens, il faudrait que ce soient précisément sur les sites qui ne font pas partie du propre cercle de confiance de l'utilisateur qu'on devrait mettre en place ce genre de foncitonnalités.

    En gros, les sites relativement ouverts l'utiliseront, et tant mieux, mais pas forcément d'autres sites qui n'y auront pas forcément intérêt.. On peut les en convaincre, mais là on entre dans l'hypothétique.

     

    Bref, commençons par cette discussion de définition de ce qu'on attend, en se donnant comme limite qu'on développe ici sur Elgg, donc côté serveur, mais pas sur un outil tiers du genre client tierce partie qui devrait aller y piocher des données (juste parce qu'il s'agit d'un autre projet).

     

    Dernière remarque : j'aimerais qu'on se fixe des choses très rapides à mettre en place, et qu'on avance non pas en construisant un grand projet, mais plutôt par petites touches immédiatement utilisables/montrables, par exemple :

    1. une première base de plugins implémentant OAuth ou autre choix de techno pour diverses versions d'Elgg - la dernière version étant loin d'être encore utilisée par tout le monde ici (et même si OAuth semble déjà implémenté -ai pas encore testé-, il faudra de toutes façons discuter entre sites de diverses versions, et puis le plugin OAuth pour la 1.6 et la 1.7 est déjà tout à fait fonctionnel -ai testé en 1.6, OK-)    ~ à ce niveau on sait déjà connecter des sites entre eux - même si ça reste virtuel
    2. puis en ajoutant des accès aux données : données du profil sans doute pour commencer, en sachant que les profils sont généralement différents selon les sites
    3. ensuite voir comment on gère les données en tant qu'objets : voir si on s'appuie par exemple sur les UUID au lieu des GUID pour identifier les objets, et si on doit inclure des vues de définition ou de rendu des objets   - même si on reste encore en lecture seule, voir comment afficher un article de blog depuis un site qui n'utilise pas de blog - ça se résout facilement, mais de diverses manières selon ce qu'on veut..
    4. après on passe peut-être à choses comme du stockage en local de données externes    -  mais on peut aussi le faire en 2e si on considère que l'accès aux données est plus urgent que la possibilité d'en avoir un rendu fidèle  -  car on a quand même souvent des objets un peu particuliers ou spécifiques à chaque site, et on ne va pas balancer un paquet de métadonnées et relations attachés aux objets sans les normaliser..  mais bon, ça peut être un point de départ intéressant

    il me semble qu'il faudrait commencer doucement, quitte à implémenter des standards d'échange progressivement, des intégrations de contenus tiers "exotiques" (objets qu'on ne rencontre pas forcément sur d'autres sites), ma fourniture de moyens de mapping ou de feuilles de définition des objets (d'ailleurs plus normalisé à paetir de la 1.8)    - en les ayant à l'esprit dès le départ bien sûr, mais sans se les imposer trop tôt, histoire d'avoir des choses suffisament fonctionnelles et montrables avant de passer trop de temps sur une usine à gaz.

     

    J'espère que ces petits éléments de réflexion au fil de l'eau va permettre de se remotiver sur ce projet intéressant, qui n'attend que d'avoir des contours plus précis pour démarrer.

     

    Je vous propose donc de poursuivre cette discussion ici même, puis que nous entamions un cahier des charges sur le wiki ("pages")

     

  • ManUtopiK le 28 octobre 2011

    Merci Facyla de (re)lancer cette discussion.

    Personnelement ce qui m'interesse le plus c'est de donner la possibilité aux utilisateurs d'un site Elgg de pouvoir se connecter à un autre utilisateur d'un autre réseau (et pas forcément sur Elgg). ET vice versa, qu'un utilisateur d'un autre réseau puisse suivre un utilisateur sur Elgg.

    Il existe un protocole ouvert qui permet de faire ça : c'est OStatus.

    Lorea, un site Elgg espagnol qui est passé de moins de 1000 membres à plus de 32000 depuis le mouvement des indignés, a plusieurs réseaux avec Elgg et ont (en partie) implémenté le protocole Ostatus pour Elgg 1.7.

    Plusieurs plugins sont nécessaires :

    elgg_ostatus

    elgg_phsb pour PubSubHubBub

    elgg_salmon

    elgg_foreign_object pour des objets tiers exotiques

    Ils ont aussi modifié le core de Elgg 1.7 et sont aussi en train de migrer doucement vers la version 1.8

     

    Le problème qui se pose, c'est justement que le coût de mise en place est lourd. Donc pas forcément accessible à tous les administrateurs...

    Il me semblait avoir vu dans la roadmap sur trac.elgg l'idée d'implémenter Ostatus dans Elgg 2.0 mais je ne trouve plus...

    Voilà à froid les pistes que j'ai.

  • Florian DANIEL ~ Facyla le 29 octobre 2011

    ça me rappelle des choses, mais ça me semblait un peu lourd à mettre en place, à l'époque.. j'y re-jette un oeil dans le weekend. Au pire, s'il suffit de packager le tout dans un plugin' & play ça peut le faire, mais évidemment s'il faut ajouter un serveur java en plus ou gérer les certificats ssl pour que ça tourne, ça limite l'usage.. bon, faut que je re-regarde tout ça plus en détail.

    On peut déjà commencer à consolider les ressources (plugins, docs, discussions) dans le wiki du groupe : il y a déjà quelques trucs.

     

    (au passage, sympa le river deck ! ..et pas mal d'autres plugins très intéressants de lorea.org à côté de ceux indiqués)

  • Florian DANIEL ~ Facyla le 29 octobre 2011

    J'adapte OAuth pour la 1.6(.4) dans un premier temps ;

    on trouve un mode d'emploi pour connecter des sites sur https://n-1.cc/pg/pages/view/9851/

     

  • François Elie le 1 novembre 2011

    Bonjour,

    Il y a trois pistes possibles:

    1) une architecture fractale des elgg qui fait que la fédération d'identité pour un utilisateur existant sur plusieurs elggs produise une aggrégation de ses profils dans un quelconque des elgg sur lequel il existe: c'est compliqué (mais intéressant en termes d'architecture et de dev) et surtout c'est inutile: il existe d'autres réseaux sociaux, il faut penser standard d'échange et agrégateur.

    2) un plugin qui permettrait d'échanger entre elggs/autres réseaux - c'est la piste qui semble explorée ici (message de Forian Daniel)

    Dans le tweeterdeck like plugin de Elgg1.8, deck river, on a quelque chose qui est *dans* Elgg

    http://community.elgg.org/pg/plugins/project/763963/developer/ManUtopiK/deck-river-18

    Je reprends une phrase de Florian Daniel:

    Personnelement ce qui m'interesse le plus c'est de donner la possibilité aux utilisateurs d'un site Elgg de pouvoir se connecter à un autre utilisateur d'un autre réseau (et pas
    forcément sur Elgg). ET vice versa, qu'un utilisateur d'un autre réseau puisse suivre un utilisateur sur Elgg.

    Pour ce qui nous occupe, le plus urgent c'est qu'un utilisateur d'un autre réseau (qui peut être un elgg)... puisse suivre un utilisateur de elgg.

    Il y a donc une troisième piste qui me semble intéressante

    3) toujours (mais au niveau architecture et pas seulement look) sur le modèle de tweetdeck: un agrégateur *déporté* chez l'utilisateur qui lui permette

    1.    de gérer la fédération éventuelle de ses identités sur plusieurs elgg où il existerait (mais en protégeant cela contre les autres réseaux)
    2.    d'agréger les flux des autres réseaux (twitter, feacebook, linkedin etc...)
    3.    de disposer sur *sa* machine des données sensibles qu'ailleurs on monnaye
    4.    évidemment de rediriger, partager, mettre en contact, etc... de manière transparente entre ses réseaux sociaux

    L'effet de ce troisième modèle me semble être 1) son indépendance à l'égard des réseaux et des versions de elgg/plugins utilisés: tout le monde pourrait y venir *avant* que elgg ne soit partout, ça fait gagner du temps... 2) qu'il encourage mécaniquement les réseaux sociaux *productifs* et partageant des ressources *lourdes* et *riches* dans la vraie vie.

    On peut penser à tweetdeck, mais aussi et surtout à yasst (pour des raisons de statut juridique du code)

    Yasst.org

    Il me semble que s'investir pour que Yasst (ou un fork de Yasst) puisse être un/le point d'entrée de l'utilisateur dans le/les elgg et autres ne serait pas du temps perdu. Il me sembe probable que les réseaux qui n'auront pas peur des agrégateurs seront les réseaux qui gagneront!

    Bien cordialement
    François Elie

  • ManUtopiK le 1 novembre 2011

    @Facyla :

    Oui, les plugins de Lorea sont vraiment intéressant. Merci pour ton retour d'expérience sur OAuth.

    @François :

    Salut à toi ! Pour la 1) : tout à fait d'accord avec toi, il faut penser standard d'échange et agrégateur. C'est pourquoi je préconise OStatus.

    C'est un peu l'idée que j'ai de fair avec le deck-river. Y intégrer la possibilité de suivre ses flux d'autres platoformes (Twitter, Facebook...) et agréger tout ça dans le deck. Mais ça demande beaucoup de boulot...

    Je ne comprend pas trop ce que tu veux dire par "on a quelque chose qui est *dans* Elgg". Tu pourrais préciser ?

    La phrase n'est pas de Florian mais de moi ;-)

    3) Dans le fond je suis entièrement d'accord avec ce pount 3). Par contre, je ne suis pas sûr que passer par un client soit la meilleure solution. Personnellement, je préfère Hootsuite à Tweetdeck (ou yasst) car Hootsuite est dans mon navigateur (Firefox). Ce n'est pas un logiciel de plus. Je peux utiliser tous les plugins Firefox dans Hootsuite entre autre. Lorsque j'ouvre un lien, paf, je ne change pas d'appli...

    Il est vrai qu'un client apporte une indépendance «à l'égard des plateformes et des versions de elgg/plugins». Mais dans un système fédéré, il serait possible d'installer sur son propre serveur une instance de Elgg pour se connecter aux autres instances. C'est certes un peu plus lourd que d'installer un logiciel sur son ordi...

    L'autre inconvénient d'un client est que des réseaux (de gens) n'ont pas les mêmes besoins. On le voit dans les plugins Elgg qui viennent de sortir. Il y en a qui développent des plugins pour s'envoyer des kiss, hugs, pokes et autres likes, et d'autres qui font des plugins pour intégrer Etherpad. Entre le ludique et le professionnel, il y a de grands écarts.

    Donc les plateformes sociales n'ont pas toutes les mêmes outils. Avec un logiciel client, tu te coupes de ces outils. Par contre avec des plateformes utilisant des standards d'échanges, il serait possible de partager uniquement des objets bien précis.

    Un exemple pour mieux comprendre : un ado pourrait sur sa plateforme partager des kiss et des likes avec ses copin/ines sur cette même plateforme ou sur une autre plateforme pour ados. Et de sa plateforme, l'ado pourrait envoyer un message à son papa qui est sur une autre plateforme prévue pour recevoir des objets "messages" mais pas des "kiss".

    ;-)

    Bref, il me semble aussi que l'indépendace des plateformes n'a pas l'air de déranger beaucoup de monde. Il n'y a cas voir la foule sur Facebook. Ceux que ça dérange migre sur Diaspora. Or il existe très peu d'instance Diaspora... Ils reproduisent le même schéma. Il est vrai que c'est plus libre... Même constat àvec SatusNet/Identica, très peu monte leur propre serveur...

    Pour revenir à nos moutons et pour envisager ça : «le plus urgent c'est qu'un utilisateur d'un autre réseau (qui peut être un elgg)... puisse suivre un utilisateur de elgg», je pense qu'il faut jeter un coup d'œil au Web API de Elgg...

    A+

     

     

     

  • Florian DANIEL ~ Facyla le 1 novembre 2011

    C'est vrai que la possibilité d'exposer ses propres API peut être intéressante à creuser aussi ;)   Tout réside à mon sens dans la méthode d'identification sur le site : une fois ce point réglé, le reste devrait couler de source (mais j'ai un petit besoin de montée en compétence préalable sur l'authentification justement).

    Pour la fonctionnalité river-deck, on pourrait très bien manipuler des flux RSS dans un tout premier temps, par exemple en autorisant l'accès à des flux RSS via des jetons configurables par l'user ..  ça me semble relativement simple à mettre en place et une piste intéressante aussi par rapport à des agrégateurs de flux privés, mais ça reste d'un intérêt limité (je veux dire : j'ai du mal à considérer de simples flux RSS privés comme les prémices d'un réseau acentré..).

     

  • Florian DANIEL ~ Facyla le 16 novembre 2011

    Concrètement :

     

    Premiers essais : j'avais commencé à adapter OAuth en partant de la version pour Elgg 1.7 de Justin Richer : quelques premiers tests et une version probablement utilisable, mais sans application fonctionnelle - je me suis plutôt penché sur la connexion avec Linkedin (aussi via OAuth 1.0a), qui intègre Oauth sans s'appuyer sur le plugin "oauth" lui-même.. bref, quelques essais "dans l'eau" sans réelle production utilisable, sauf la version adaptée d'OAuth pour Elgg 1.6

     

    Première pré-version de démonstration : après cette première série, retour à la feuille blanche - j'ai préféré repartir de la version "1.6" de "lorea" (toute la plateforme lorea" est disponible sur Github et Bitbucket) : cela m'a semblé plus cohérent de s'appuyer sur une version utilisée conjointement avec une série d'autres plugins utilisant OAuth.

    Là ça fonctionne déjà mieux !  Mise à part la question de l'heure interne des serveurs (qui peut facilement poser problème selon les contextes d'utilisation, celle-ci devant être à peu près identique), cela produit quelques premiers résultats :

    • possibilité de connecter 2 sites Elgg entre eux, dans un sens comme dans l'autre : le plugin fait office de client et de serveur
    • gestion des "consumer" (clef d'API pour les applications tierces enregistrées sur un site, et permettant d'accéder à ses données sur ce site depuis ces applications)
    • gestion des jetons d'autorisation
    • récupération de ses contacts sur le site distant

    Pour le moment, cela reste encore très "alpha" : pas vraiment stable, une partie de la config "en dur" dans le code, certains paramètres gérés par un admin (il faudrait que ce soit directement par l'user), etc.   ..et étransgement une connexion qui fonctionne mieux dans un sens que dans l'autre (le plugin étant strictement identique sur les 2 sites sur lesquels il est testé..).

    Bref, c'est un début ; j'essaie au moins de rendre les paramètres un peu plus configurables et le plugin plus générique pour le tester dans d'autres contextes.

     

    Sinon la version pour Elgg 1.8 d'OAuth semble intéressante. Je ne compte pas la tester (une version à la fois), mais si quelqu'un en a eu l'usage ce serait intéressant de voir ce qui a pu être réalisé avec ?

     

  • juliendangers le 21 mai 2012

    je viens aux nouvelles =)

    je voulais savoir si ce projet avait avancé? sinon existe-t-il un repo git ou autre?

    Il faut faire émerger une idée comme celle-là =D

  • ManUtopiK le 21 mai 2012

    Non, de mon côté je n'ai pas trop avancé...

    Un repo est une bonne idée, mais il faudrait comme le titre du post l'indique, élaborer une roadmap d'abord.

    Pour des pistes, je vous conseille de faire un tour ici :

    https://bitbucket.org/rhizomatik

    A+

  • Florian DANIEL ~ Facyla le 7 juin 2012

    Pas avancé non plus depuis les derniers messages..

    Il y a pas mal de manière de concevoir ce truc, qui déterminent les choix à faire. Perso j'imagine qu'on puisse packager un mini-site elgg en version portable sur une clef usb (ou son serveur perso, ou utiliser le site mis à disposition par un tiers de confiance), et utiliser ce site personnel (ou partagé) pour accéder à ses autres participations en ligne. Je sais qu'il existe des projets pour faire cela de manière indépendante d'Elgg, mais cela ne m'intéresse pas : je regarde la quesiton du point de vue de ce framework et de ce qu'il faudrait faire pour permettre des backend aisés à installer (et éventuellement configurer) pour que cela puisse devenir un plugin qu'on installe quasiment sans avoir à y réfléchir et que cela devienne en quelque sorte la norme (comme cela devient malheureusement le cas pour les FB Connect).

    J'y vois donc un intérêt fort pour une forme de fédération de sites, gérée par les membres directement, mais facilitée par les opérateurs du site.

    Le problème principal de ce projet est le temps considérable qu'il faut y passer quand cela doit s'ajouter à son activité normale. En ce qui me concerne, je peux difficilement dépasser le stade du prototype en l'absence de client intéressé pour soutenir le projet. Collectivement on peut aller plus loin, mais la même question se pose pour tout le monde je suppose ?

    Avancer via Github peut être intéressant. Il faudrait déjà qu'on ait un petit groupes de sites prêts à tester et expérimenter, ne serait-ce que pour tester les prototypes.

    Vu le temps qui passe, je pense que je travaillerai maintenant plutôt en 1.8 sur ce projet, tout en conservant une compatibilité en 1.6 (ce que la structure des objets facilite grandement).

     

    Avis à mécènes donc : vous souhaitez soutenir les réseaux acentrés ? plusieurs idées et projets ont été avancés, reste à les préciser (roadmap), et à soutenir la mise en place d'une équipe pour les développer => on est déjà trois potentiellement intéressés  Rigolant