Reflexion sur oAuth suite
Par JcDenis le dimanche 21 novembre 2010, 15:45 - Actu - Lien permanent
Dans le billet précédent
je mettais en place les bases d'une réflexion sur l'implémentation de
oAuth dans Dotclear. Aujourd'hui j'hésite entre plusieurs manières de
répartir le travail entre diffèrent plugins.
En prenant pour exemple l'ajout des boutons d'identification de Twitter ou Facebook sur les commentaires d'un blog voici une petite représentation d'un fonctionnement possible:
Le problème en utilisant un tel schéma est la multiplication des plugins liés entre eux. Ici pour ajouter le bouton de Twitter il faut le plugins OptionForComments, xxxTwitter, oAuthManager et kUtRL (si on veut réduire les liens) c'est très lourd! Mais les possibilités d'évolution et de suivi des API par exemple sont grandes et chaque plugin à une seule tache à accomplir.
L'autre possibilité serait que chaque plugin comme optionsForComments ai ses propres fonctions Twitter, Facebook ou autre ce qui réduit les dépendances entre plugins quitte à réécrire ses fonctions pour chaque plugin voulant dialoguer avec Twitter et autres...
Et vous qu'en pensez vous?
PS: Je ne détail pas ici le fonctionnement de oAuthManager qui permettra une gestion complète des clients (et plus tard des serveurs)
Évaluer ce billet
- Note : 0
- Votes : 0
Commentaires
Personnelllement je serais plutôt pour le 1er choix, un plugin ne fait qu'une chose mais le fait bien — un peu comme comme Dotclear pour les blogs en quelque sorte.
Je ne crois pas que ce soit un problème d'imposer l'installation de plugins de service afin d'utiliser un plugin tiers.
Évaluer ce commentaire
Merci Franck, j'espérai un peu cette réponse, et osku pense de même... Je vais donc commencer la séparation des fonctions.
Y en a qui vont râler car je vais mettre un bazar dans mes plugins!
Évaluer ce commentaire
Je plussoie Franck et Osku, pour moi "un plugin = une fonction" convient tout à fait. Après il faut gérer les dépendances correctement (entre autres les problème de versions des dépendances).
Le logiciel libre (Linux entre autre) fait de même, certains package ne s'installent qui si leurs dépendances sont déjà installées.
Pierre
Évaluer ce commentaire
La première solution est le meilleur choix ... sinon bonjour la maintenance des évolutions ...
Évaluer ce commentaire
footcow,
ouep j'ai déjà bien avancé sur la première solution et en plus j'ai eu la bonne surprise de voir qu'Identi.ca (avec statusNet) utilisait aussi oAuth donc il sera intégré de base.
Sinon pour les maintenances... heu... comment dire... la porté est encore plus grande car même kUtRL va faire une bonne cure de modifications... sans compter que les anciens plugins comme TaC vont trainer un moment un peu partout (lab, dotaddict...) Ça va être le bordel! D'où ma rage envers moi-même dans mon précédent billet.
Évaluer ce commentaire
est-ce qu'on gère les dépendances entre plugins dans dotaddict ?
Sinon je me demande si un plugin tel qu'oAuthManager n'aurait pas sa place à terme dans le core de dotclear ou dans clearbricks. Enfin moi je dis ça c'est juste pour foutre le boxon
Évaluer ce commentaire
biou,
La partie oAuth pourrait être intégré à clearbricks à terme mais il y a trop de changements sur la spé 2.0 d'oAuth pour faire un truc stable aujourd'hui.
Quand à la gestion des clients/serveurs dans le core de Dotclear, je ne pense pas que ce soit une bonne idée, oAuthManager n'est pas nécessaire au fonctionnement de DC et à mon avis ne le sera jamais, c'est donc le rôle d'un plugin.
Enfin, non DA ne gère pas les dépendances, c'est lors de l'installation du plugin que celui-ci grince et fait savoir qu'il lui manque un copain.
Évaluer ce commentaire
Végétalien durant un an faire l’objet d’une conversation j'ai mes opinions.
Évaluer ce commentaire