04-01-2011, 01:43 AM
Ah mais je ne remets pas en cause l'intérêt de la question. Bien sûr que c'est intéressant ! Ça permet de discuter du sujet de fond "système maison VS système éprouvé par la communauté" ! 
Il faut relativiser les avantages (sur le plan des performances) du code "maison". C'est plus léger au début, quand le système ne sait rien faire, on se sent fier de son minimalisme : ensuite — puisqu'on est dans la vrai vie — de nouveaux besoins émergent. On a besoin d'une fonctionnalité, qui consiste à générer un token à usage unique (pour les mails d'activation ou les procédures d'oubli de mot de passe, notamment), et à en régénérer une fois que le précédent est utilisé. Dans Authlogic, il suffit d'avoir une colonne perishable_token pour que cette fonctionnalité soit prise en charge. Bref, le code s'enrichit, se complexifie. Le système maison perd de son minimalisme, l'écart de performance tend à diminuer.
Ensuite, l'évolution du code. Authlogic est beaucoup utilisé. Son code est souvent mis à jour : pour la sécurité, pour les performances ou que sais-je encore. Est-ce parce qu'il est truffé de bug ou lent et lourd ? Ou est-ce parce que plusieurs personnes ont cherché à l'améliorer ? Le système maison sera-t-il aussi bien maintenu ?
Enfin, un autre point en faveur des outils éprouvés : les tests. Dans la communauté Ruby, il y a une véritable culture du test : n'espère pas soumettre une fonctionnalité à l'équipe d'Authlogic, de Devise ou même de Rails si tu ne fournis pas les tests associés. Authlogic est très testé. Le système maison aura-t-il sa batterie de tests (et seront-il maintenus à jour) ?
Attention donc de ne pas oublier trop d'éléments lors de la pesée des pours et des contres !
Sephi-Chan
Il faut relativiser les avantages (sur le plan des performances) du code "maison". C'est plus léger au début, quand le système ne sait rien faire, on se sent fier de son minimalisme : ensuite — puisqu'on est dans la vrai vie — de nouveaux besoins émergent. On a besoin d'une fonctionnalité, qui consiste à générer un token à usage unique (pour les mails d'activation ou les procédures d'oubli de mot de passe, notamment), et à en régénérer une fois que le précédent est utilisé. Dans Authlogic, il suffit d'avoir une colonne perishable_token pour que cette fonctionnalité soit prise en charge. Bref, le code s'enrichit, se complexifie. Le système maison perd de son minimalisme, l'écart de performance tend à diminuer.
Ensuite, l'évolution du code. Authlogic est beaucoup utilisé. Son code est souvent mis à jour : pour la sécurité, pour les performances ou que sais-je encore. Est-ce parce qu'il est truffé de bug ou lent et lourd ? Ou est-ce parce que plusieurs personnes ont cherché à l'améliorer ? Le système maison sera-t-il aussi bien maintenu ?
Enfin, un autre point en faveur des outils éprouvés : les tests. Dans la communauté Ruby, il y a une véritable culture du test : n'espère pas soumettre une fonctionnalité à l'équipe d'Authlogic, de Devise ou même de Rails si tu ne fournis pas les tests associés. Authlogic est très testé. Le système maison aura-t-il sa batterie de tests (et seront-il maintenus à jour) ?
Attention donc de ne pas oublier trop d'éléments lors de la pesée des pours et des contres !
Sephi-Chan