Journal Les blogs et la formation

Posté par (page perso) .
Tags : aucun
14
25
jan.
2010
Depuis août 2009 j'ai une apprentie informaticienne pour le CFC. Cette formation est réglementée et prévoit, entre autres choses, la création d'un journal de travail tenu par l'apprenti (quotidien). Ce journal doit ensuite être lu et validé par le responsable de formation (la fréquence dépend du métier, allant de chaque mois à chaque six mois).

Dans beaucoup de cas, il s'agit simplement d'un cahier ou classeur contenant un résumé de la journée, signé par le responsable. En réfléchissant un peu, j'ai rapidement fait l'analogie avec les blogs. En Suisse, les signatures numériques (GPG par exemple) sont reconnues comme étant valide (au moins autant qu'une signature manuscrite).

Je me suis donc mis en tête de trouver un logiciel de blog qui me permettrait de faire tout ça :
  • Signature GPG des billets
  • Authentification LDAP
  • Gestion des droits simples (apprenti écriture, formateur signature uniquement, personnes authentifiées lecture uniquement)
  • Multi-utilisateurs (plusieurs apprentis et/ou formateurs)
  • Fichiers textes (pour le stockage des billets)
  • Langage creole
Après avoir passé un bon moment à chercher le logiciel qui me plaisait, je me suis rendu compte que celui-ci n'existait pas (ou était trop bien caché (ou je suis une pive pour chercher)).
Je me suis donc fait un cahier des charges du blog de mes rêves (en fait j'ai failli partir dans le développement d'un petit truc à la rache (ISO 1664), mais j'ai réfléchi).

Ensuite je me suis dis qu'il y aurait peut-être d'autres personnes intéressées par ce projet. Il est même possible que ce blog existe quelque part (mais bien caché). Il se peut même que d'autres personnes aient des idées intéressantes à ajouter au cahier des charges. Et pire encore, il y a peut-être des gens intéressés à participer au développement de ce blog.

Il s'agit donc d'une sorte de "Request For Comments" avant que je me lance dans le création de ce blog.

PS: Bien entendu ce blog est (sera) en licence GPL.
  • # Dokuwiki en fait une partie (mais pas tout)

    Posté par . Évalué à 2.

    Dokuwiki gère...
    - l'authentification LDAP
    - la gestion des droits (potentiellement dérivés de groupes d'utilisateurs de l'annuaire)
    - les utilisateurs multiples
    - le stockage sous forme de fichiers texte plutôt que sous formes d'entrées dans une base de données

    En revanche...
    - Son langage n'est pas le creole même s'il s'en rapproche
    - Il ne dispose pas nativement de fonctionnalités de signature des pages et aucun plugin allant dans ce sens ne semble pour l'instant disponible... encore que le développement de plugins pour dokuwiki ne semble pas trop compliqué... Peut être est-ce à creuser.
    • [^] # Re: Dokuwiki en fait une partie (mais pas tout)

      Posté par (page perso) . Évalué à 2.

      Et il a un plugin pour faire blog. J'ai regardé mais ça reste quand même un wiki (et on l'utilise déjà au travail pour la documentation, donc on le connaît bien).

      Mais toute la partie "wiki" pose problème. C'est des fonctionnalités à, presque, supprimer (ou du moins désactiver). Donc niveau charge de travail je sais pas si c'est le mieux. Surtout pour amputer pleins de fonctions à un excellent outil.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Dokuwiki en fait une partie (mais pas tout)

      Posté par (page perso) . Évalué à 3.

      Il y a un plugin pour que DokuWiki interprète la syntaxe creole.
  • # La RACHE

    Posté par (page perso) . Évalué à 5.

    La RACHE, pas la rache !
    • [^] # Re: La RACHE

      Posté par . Évalué à 4.

      Yep, mais c'te métode s'applik aussi à l'orthograf !
  • # AGPL

    Posté par (page perso) . Évalué à 7.

    Pourquoi ne pas le publier plutôt sous Affero GPL ?

    Sous GPL seule, rien n'empêcherait quelqu'un de le modifier lourdement, sans publier ses modification, et de l'utiliser pour héberger des gens sans respecter leur liberté.

    Avec AGPL, il devrait publier ses modifications à ses utilisateurs.
    • [^] # Re: AGPL

      Posté par (page perso) . Évalué à 2.

      Heu parce que quand je penses licence Libre, j'ai GPL qui s'allume dans la tête. Je ne connais pas AGPL, mais si c'est mieux pour les projets Web, je veux bien l'utiliser. Je regarderais ça. Merci.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Django

    Posté par (page perso) . Évalué à 1.

    Django, un framework python pour le web,
    Gère directement où via des plugins quasiment tout ça.

    L'exception étant la signature par GPG des billets mais à l'aide de la boîte à outils de python il doit être possible de bidouiller trés rapidement et de manière assez solide.

    Une gestion des droits fine permettrait de mettre en place les limitations que tu souhaites (y compris l'impossibilité de la dé-signature et de la modification).

    Le stockage dans une base de données se fait de manière très simple, et je crois qu'il existe un pluggin pour utiliser des fichiers textes (au pire une base SQLite qui est standalone elle et ne nécessite rien en sus de python pour être exploitable).

    Je pourrais continuer comme ça mais là n'est pas le sujet, en bref :
    C'est comme ça que je ferai.

    Coté désavantage :
    Le fait que tu cherches quelque chose de standalone est un soucis mais les package python (les eggs) gèrent relativement bien les dépendances, et dans le cas présent tu pourrais assez facilement te limiter à Django, si tu acceptes de recoder 2 ou 3 trucs. Et sinon juste l'installation de 2 pluggins pour Creole et LDAP.
    • [^] # Re: Django

      Posté par (page perso) . Évalué à 5.

      Je sais que je vais m'attirer des problèmes en disant ça, mais vu la popularité de PHP, le fait que les cours de programmation Web en apprentissage sont donnés avec PHP et le fait qu'on trouve plus facilement un serveur PHP installé, je crois que je vais rester avec PHP comme langage.

      Ce projet serait prévu pour des apprentis, formés avec PHP, et des entreprises qui tournent, pour la majorité, avec Windows Server.
      Au cours professionnel, l'installation d'un serveur Web Apache/PHP/MySQL est fait sur Windows (si, si, c'est terrible mais c'est comme ça (Linux entre dans les cours, mais c'est pas encore ça)).

      Donc utiliser du python c'est prendre un chemin qui assure que le projet sera utilisé que par moi, ce que je ne souhaite pas (sinon je serais parti à La RACHE (c'est bon comme ça l'orthographe ?)).

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Django

        Posté par (page perso) . Évalué à 2.

        Tiens, pour les cours, certains autour de moi commencent à utiliser la virtualisation afin que chaque enseignant amène "ce qu'il veut" packagé et testé comme il faut.

        L'admin sys du parc a juste à installer un VirtualBox (ou du même genre).

        Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

  • # Et les blogs existants ?

    Posté par . Évalué à 2.

    Wordpress est un très bon moteur de blog, Dotclear aussi. Je ne crois pas qu'ils aient toutes les fonctions requises, mais les deux permettent l'utilisation de plugins. Pourquoi ne pas partir là dessus et ne faire que ce qui manque ?
    • [^] # Re: Et les blogs existants ?

      Posté par (page perso) . Évalué à 4.

      Je ne sais pas le temps nécessaire pour changer le stockage vers fichier texte et pour changer le rendu (en utilisant creole) n'est pas plus grand que faire un petit moteur avec juste les fonctions nécessaires.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Extension Firefox

    Posté par (page perso) . Évalué à 2.

    De toute façon pour signer les billets avec GPG, il va te falloir une extension dans le navigateur, non ? Tu as regardé du côté de FireGPG ? Je pense que ça pourrait tout à fait répondre à ce besoin.

    Ensuite, je serais d'avis d'ajouter les fonctionnalités manquantes à un moteur de blog genre dotclear ou wordpress, comme l'indique le commentateur précédent.
    • [^] # Re: Extension Firefox

      Posté par (page perso) . Évalué à 2.

      Dans le cahier des charges (qui est un peu plus détaillé que la présentation ici) j'ai indiqué que le blog ne gère pas la signature (je laisse ça à FireGPG) mais comprend que le message est signé et éventuellement contrôle la validité de la signature et l'intégrité du texte et tout ça.

      Pour Wordpress et Dotclear, il semble que ce soit base de données uniquement, de plus il me semble qu'il faut changer tout le rendu pour qu'on puisse utiliser du creole comme langage.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # Pourquoi faire simple…

    Posté par . Évalué à 4.

    Je sais que je vais me faire taper, mais… les mails ? Moyennant la mise en place de liste si on veut pas une liste d’expéditeur à rallonge, je suppose que ces mêmes listes doivent savoir gérer les droits…

    Bon c’est clair que ça en jette moins.
    • [^] # Re: Pourquoi faire simple…

      Posté par (page perso) . Évalué à 3.

      En gros il y a le message de l'apprenti et en réponse il y a le message de l'apprenti signé par le responsable (et plusieurs réponses s'il y a un responsable).
      L'apprenti signe son message, ce qui empêche le responsable de le modifier, et le responsable signe le message signé.

      Ça pourrait fonctionner, même plutôt bien, mais je trouve ça moins intuitif qu'un blog, par contre niveau travail à faire : rien, tout est déjà en place (serveur mail, gnupg, un mailman (ou similaire)).
      Mais je vais quand même rester sur l'idée du blog, je crois qu'il faut un truc intuitif.

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: Pourquoi faire simple…

        Posté par (page perso) . Évalué à 2.

        Quand on doit faire un compte rendu régulier, l'écrire et l'envoyer à une adresse, ce n'est pas intuitif ? Là, je ne vois pas ce qu'on peut faire…
        • [^] # Re: Pourquoi faire simple…

          Posté par (page perso) . Évalué à 2.

          Le côté renvoyer le compte rendu signé à la même adresse ... ce contenu peut être renvoyé plusieurs fois (si plusieurs responsables, ce qui mon cas au job, on est deux). Donc ça va faire une file de discussion avec trois mails contenant quasiment la même chose (même texte, signature différente).
          Ensuite le rendu c'est pas top. Soit les mails en HTML (que je m'efforce de proscrire parce que je suis un vieux con) pour avoir les liens hypertextes (pratique dans un journal de travail) ou soit en texte avec des liens[1]
          Donc c'est pas le plus intuitif qui soit à mon sens. Finalement si on a plusieurs apprentis, ça va faire quand même un peu charlot d'avoir X fois 3 mails contenant le même contenu (et en plus en terme d'économie de place c'est pas le plus optimale).

          [1] hypertextes

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

  • # «Blocage de la suppression d'une signature»

    Posté par . Évalué à 2.

    Je me suis attardé quelques instant sur la partie «Blocage de la suppression d'une signature».

    La pérennité des données va dépendre du bon vouloir de la personne ayant la main sur le blog, ou sur ton support WORM (si tu comptes utiliser cela). Dans ce dernier cas on peut toujours imaginer que quelqu'un détruise le support de donnée. Pour être sur qu'une signature ne puisse être effacée, je te conseille d'utiliser une des caractéristiques des signatures numériques (Signature_numerique). Elles sont irrévocables, ce qui signifie que d'une fois une signature établie, la personne qui l'a mise ne pourra nier l'avoir fait. Les parties en présences (Apprenti, Formateur) devraient donc signer numériquement les deux le billet, et d'une fois que cela est fait, récupérer chacun de leur côté le fichier doublement signé. Ainsi il n'y a pas de main-mise sur les données de la part d'une ou l'autre de parties. De plus la signature attestera si le texte qui a été signé est bien le texte contenu dans le fichier et rendra donc caduque toute modification apportée après la signature.

    J'opterai aussi pour un fichier XML contenant deux parties, une première contenant l'article et une autre contenant les signatures. Rien ne t'empêche après d'utiliser du créole dans la partie «article/» pour la mise en forme.

    exemple:

    «billet»
    «article»{Texte de l'article}«/article»
    «signatures»
    «signature»{Signature de l'apprenti de la partie contenu dans «article/»}«/signature»
    «signature»{Signature du formateur de la partie contenu dans «article/»}«/signature»
    «/signatures»
    «/billet»


    Ainsi ton fichier XML, d'une fois récupéré, atteste que l'apprenti et le formateur ont les deux signés le billet. Et si un jour vérification doit être fait de l'intégrité des signatures, la clef publique de chacune de parties permettras de vérifier si l'article qu'ils ont signés et bien celui contenu dans la balise «article/». Si tel est le cas il NE pourront NIER avoir signé ce billet, aussi bien le formateur que l'apprenti. Quand à la récupération automatique des fichiers j'opterai pour un flux RSS à la manière des podcasts, pour permettre à chacun une relève automatique des fichiers (d'une fois signés bien sûr).

    Pour le reste des fonctionnalités, cela s'apparente plus à du web pur et dur et j'imagine bien qu'il ne devrait pas trop y avoir de problèmes.

    En espérant que ça aille pu t'être d'une quelconque utilité :)
    Fabien

    PS: Désolé pour le XML pas tant «conforme», mais je n'arrivais pas à mettre les bonnes balises.
    • [^] # Re: «Blocage de la suppression d'une signature»

      Posté par (page perso) . Évalué à 2.

      Le problème des signatures irrévocables est le suivant :

      L'apprenti aura accès aux serveurs (il apprend le métier et l'administration des serveurs de la boîte en fait partie), donc ouvrir un fichier texte sur vi, taper "dd:wq" et la signature n'est plus là. Le formateur aussi peut le faire. En cas de litige, le formateur/apprenti peut supprimer quelque signature et dire "voilà personne n'a contrôler mon travail, ...".

      Donc éviter que la signature soient supprimée, la méthode c'est la réplication. Il y aura sur les bandes de backup le fichier signé, si l'apprenti ne fait plus confiance à son responsable (en cas de litige), il peut copier les fichiers sur un CD-Rom, sur son serveur d'hébergement gratuit, sur son gmail, sur son disque dur USB. Le formateur aussi.

      Nier la signature on ne peut pas le faire (à moins de prouver que l'apprenti a eu accès à la clé privée et au mot de passe du formateur), mais c'est protéger la suppression de la signature elle-même qui est important. Dans ton exemple de fichier "2dd:wq" et il n'y plus de signatures.

      En fait ce qui est important :
      - Que l'apprenti fasse son journal de travail (obligation légale)
      - Que le formateur lise le journal de travail et le signe (obligation légale)
      Donc la signature de l'apprenti n'est pas importante (possible, mais pas nécessaire). À aucun moment l'apprenti va dire "je n'ai pas fait mon journal de travail" c'est lui qui est pénalisé.
      Par contre il devra contrôler que le formateur ne supprime pas des journaux (pour dire "il n'a pas fait son travail"), là la signature n'aide en rien. Par contre on peut imaginer qu'à chaque exportation des données le système appose une signature lui appartenant pour prouver que les données viennent bien de lui (je vais ajouter ça (en fait juste une liste de somme de contrôle de chaque fichier, cette liste étant signée par la clé du système)).

      "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: «Blocage de la suppression d'une signature»

        Posté par . Évalué à 1.

        Peut-être me suis-je mal exprimé. Je voulais en effet dire que le fichier ne peut-être sauvé en un seul endroit, et que pour pallier cela il faut que chaque partie s'occupe de garder une copie des données pour prouver sa bonne foie au cas ou. D'où l'idée du flux RSS (ex: podcast) pour que chacun puisse mettre en place chez lui un système qui télécharge automatiquement chaque billet d'une fois qu'il a été signé par les deux partis.

        On peut imager ça tel un contrat réalisé sur papier: il est fait à double exemplaire, et chaque personne garde une copie du contrat munie des deux signatures. Dans votre cas, chaque personne signe le billet, et ensuite récupère une copie du billet doublement signé.

        Si quelqu'un modifie le billet original sur le serveur pour supprimer les signatures, l'autre personne à une copie du fichier sauvegardé chez lui, et peut prouver que l'autre personne l'avait effectivement signé, ceci dans un sens comme dans l'autre.

        L'idée de la signature de l'apprenti, c'est plus dans l'idée ou le projet serait sous une licence libre, et qu'il risque d'être réutilisé dans d'autres sociétés avec des formateurs peu scrupuleux. Les apprentis doivent aussi avoir le droit de se défendre en cas de malveillances du formateur.
        • [^] # Re: «Blocage de la suppression d'une signature»

          Posté par (page perso) . Évalué à 2.

          Je penses que la liste des billets avec les sommes de contrôle (sha-256) de chaque billet


          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA256

          b88d14ee22bdd7d7ad5978cd91805ac540ff63d6606c4700464e4eb3c32924d3 fichier1.txt
          135a0df2fa26c6be9de03462f45539d2b5bce286f34bebbe1b112cde14a97afc fichier2.txt
          a4f086b848a1883bd7933e3f04e50a8bf4a538fc90b6cc6cea175ae0b33d824a fichier3.txt
          3b662c91914cedfd75e25dcc8a1621fc6dc64a29307d984dbd6fe49977cf6935 fichier4.txt
          98a3bfde6619b2aa6df15cd532c64f1949b3c045feb62f47616e198cb364c640 fichier5.txt

          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1.4.10 (GNU/Linux)
          Comment: Fausse signature

          iQIcBAEBCAAGBQJK8aIHAAoJEMFfL/bTFBa4kUgQAIaeNtpeu+B1hb/djbjt1tKk
          B3upiJP4pFQVnt9SMCu9Rp4FPLxAsuchRN80uJB4QlFzJuGmLi4HvHKBf23M1PHm
          6z8QH+UFYlMo2DPkRw+480KmJp9PpdxTvoYXwI02NLGuJrolZ9+IfqQLRvpcv/OH
          j4r9UkZzHq/cEzBo5tK0QSOBupBY8p5xkaGQ8LwvUd9ZwvE0rpC3Rz9pT40kGpn8
          K3mHLB+Ui0xZt8Oa3TdM506t9qyuWNooGaU91LEGGdJ0SeIGKzRolQYiMxQwmMHa
          WYUKhGd+X1pmifTpvTXZEtsBmX/DjSzswV4ihjUdUMaGpTPAgAavbgA4/YcVEhVR
          URAKEYjHQtaTvhPgCdcjzDDzaZ0uIeKuR8zjbwieCNDgY1GQpbCxlfrZzSHUdYX6
          5U1m/Bb0u42OYJZXE+sz8pwbF92KxkWSqC/e6+K4OOrknvUI27cU8kcEhGcsLgOf
          gI+f4Vt30pi6fEFAEMy39I3LKDePC45UK2EFxrYVVHhZZN+q1hPIY2dIQG57ci4l
          u/d9lnzI24f6tB5edIt3AnuJoWsXnEdp1zCYvrkYZ3JAYHdsautEugn5F5d23Z35
          Y0IBhVdvSsiTPbxHjoOlL4r1UxOTYn8m46kdkr0cY+/3O4Sh5BFUIkTeHkrGu+W5
          QXO4VhcEYEKcIi7Rj6c4
          =RRLN
          -----END PGP SIGNATURE-----


          Permet d'obtenir le résultat souhaité (preuve que l'apprenti fait son travail et que son travail n'a pas été modifié) et reste plus simple à gérer.

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: «Blocage de la suppression d'une signature»

          Posté par (page perso) . Évalué à 2.

          Mais tu as raison en fait. Il faut la signature de l'apprenti. La clé du moteur de blog peut être modifiée trop facilement (pas de mot de passe ou mot de passe connu).

          Donc on ajoute les signatures des deux (et en du coups d'autant de personnes qu'on veut). Comme les fichiers _doivent_ être au format wiki creole (pas de xml), on peut utiliser les balises <<>>.

          Genre :

          <<>>
          Aujourd'hui blablabla ...
          <<>>

          <<<signature:etienne@example.com: [signature] >>>
          <<<signature:paul@example.com: [signature] >>>

          "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

          • [^] # Re: «Blocage de la suppression d'une signature»

            Posté par . Évalué à 1.

            Le XML je l'aurais bien vu pour l'interopérabilité. Par exemple c'est possible qu'un jour un programme soit crée pour contrôler toutes les signatures d'une série de fichiers, ou pour visualiser un fichier avec contrôle les signatures à l'ouverture.

            Je me mets à la place des développeurs qui n'aimeraient sûrement pas devoir réaliser un parser pour analyser ton fichier, mais utiliser simplement les outils XML existants pour séparer les signatures de l'article

            Enfin je dis ça dans un souci de perfectionnisme. C'est clair que ça complexifiera un peu la tâche pour afficher les articles dans le blog. Mais je me dis que tant qu'a faire les choses, autant les faire bien non ;-) ?
            • [^] # Re: «Blocage de la suppression d'une signature»

              Posté par (page perso) . Évalué à 4.

              Je souhaite utilise le langage creole : http://wikicreole.org/ pour plusieurs raisons :
              - C'est une syntaxe wiki (13 wikis la supportent, d'autres sont en cours), donc syntaxe simple à apprendre et utiliser
              - C'est pas ISO ou W3 ou ... mais c'est une collaboration entre plusieurs projets de moteur wiki
              - C'est lisible facilement par l'être humain
              - Ça contient tous ce qui est nécessaire
              - Il existe des parsers pour Java, Perl, Python, Javascript et PHP.
              - Écrire journal de travail en XML c'est pas ce qu'il y a de plus pratique.
              - Mélanger _deux_ syntaxes (XML comme enveloppe du document wiki creole) alors qu'une seule contient tous les éléments, ce n'est pas la meilleure solution
              - Si on sépare en deux documents, RDF en Notation 3 aurait ma préférence

              Faire du XML n'implique pas "faire les choses bien".

              "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

              • [^] # Re: «Blocage de la suppression d'une signature»

                Posté par . Évalué à 3.

                Je ne peux qu'être d'accord avec toi: un moteur de blog ou wiki doit être fait pour simplifier la vie de celui qui le remplit.

                En fait la personne à qui tu réponds ne fait que me conforter dans mon idée : les devs utilisent de puls en plus XML par confort, au détriment des utilisateurs
                Je cite :
                Je me mets à la place des développeurs qui n'aimeraient sûrement pas devoir réaliser un parser pour analyser ton fichier, mais utiliser simplement les outils XML existants pour séparer les signatures de l'article

                Jen e veux pas relancer le débat que l'on a eu par ailleurs, mais cette phrase est symptomatique. Attention, je ne dénigre pas l'usage de XML, je trouve ça très bien pour des documents tels openoffice, SVG, etc .... qui sont des documents qui normalement n'ont pas à être manipulés par des humains. Par contre, lorsqu'il doit y avoir manipulation humaine (fichier de conf, wiki), je trouve que XML n'est pas approprié.
                • [^] # Re: «Blocage de la suppression d'une signature»

                  Posté par . Évalué à 1.

                  Je suis tout à fait d'accord avec vous deux, quand ils commencent même à utiliser des fichiers de configurations clef-valeur en XML ça devient totalement inutile et c'est l'horreur.

                  Mais dans ce cas je pensais effectivement à une enveloppe XML contenant ton article au format creole. Ça c'est une question de goût et si tu penses que les balises creole conviennent parfaitement pour l'usage dont tu as besoin et bien ... départ :-) !
  • # Les grandes lignes sont tracées

    Posté par (page perso) . Évalué à 2.

    J'ai avancé un peu dans la description du projet en mettant clairement en place comment je souhaitais structurer le stockage et quelques fonctions de base (créer, éditer, supprimer, lire, chercher). Si vous avez des commentaires ou des idées : http://www.tchetch.net/wiki/formation/outils/blog/implementa(...)

    "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

    • [^] # Re: Les grandes lignes sont tracées

      Posté par . Évalué à 2.

      L'utilisation de l'UUID me fait un peu sursauter. Pourquoi vouloir imiter la forme d'un UUID alors que la génération n'a strictement rien à voir ?

      Un identifiant d'une forme plus simple ne ferait-il pas l'affaire ?

      The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

      • [^] # Re: Les grandes lignes sont tracées

        Posté par (page perso) . Évalué à 2.

        À priori la fonction utilisée par mimec (en lien) respecte la section 4.4 de la RFC 4122 (http://www.ietf.org/rfc/rfc4122.txt), donc c'est bien un uuid (mais je peux me tromper).

        Sinon un hash aurait été possible, mais réellement ça change rien, je veux dire que le nom de fichier ait la forme "aaaa" ou "a-a-a-a", c'est du pareil au même.
        Finalement en utilisant des uuid comme prévu par la RFC 4122, ça donne une garantie de pouvoir importer les données sur un autre blog sans risquer de collisions.

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

        • [^] # Re: Les grandes lignes sont tracées

          Posté par . Évalué à 2.

          Ah oui, effectivement il est prévu générer des UUID à partir de données aléatoires sans tenir compte du matériel. Comme la nature est bien faite. :)

          Je ne conteste pas l'utilisation d'UUID, ça me donne seulement l'impression d'utiliser quelque chose de surdimensionné pour identifier les billets d'un blog.

          The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

          • [^] # Re: Les grandes lignes sont tracées

            Posté par (page perso) . Évalué à 2.

            La nature est bien faite, en effet.

            Sinon je crois pas que c'est surdimensionné. J'ai besoin d'un identifiant unique, c'est un identifiant unique qui fait 36 caractères de longueurs et c'est utilisé comme nom de fichier. Un nom de fichier de 36 caractères c'est raisonnable.
            Le vrai problème, pour moi, c'est que ce n'est pas très "humain". Trouver un billet par son fichier est compliqué (il faut automatiquement un logiciel pour le faire), mais avec un script "sh" on arrive à le faire, donc c'est encore assez raisonnable.
            Finalement je me laisse la possibilité de prévoir un répertoire "by-name/" qui contiendrait des liens symboliques ayant comme nom le titre du billet, la date, l'auteur, ... ou toutes les possibilités en même temps. Mais dans un premier temps, je penses que c'est déjà bien suffisant (parce que le "user-friendly" n'est pas prioritaire).

            "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.