À propos de plyme

Antoine a ouvert un site pour Plyme, un projet d’outil d’écriture collaborative. Vu que pour l’instant, je n’arrive pas à voir le site web (je soupçonne que le DNS est encore aux fraises, je vais m’occuper ici.

Le but du jeu serait de faire quelque chose qui ressemble à un Wiki, mais qui permette de cracher en fin de compte un texte linéaire, idéalement avec des informations de mise en page. Cela implique deux choses, d’abord on ne peut pas simplement avoir des pages qui virevoltent dans tous les sens. Ensuite si on veut pouvoir travailler de manière collaborative, il faut un mécanisme pour gérer les accès concurrents.

Ma première intuition serait que le système comprenne une unité de base qui soit la plus petite entité manipulable. Cela correspondrait à une image de base, un petit texte, une définition. L’idée serait que ces entités ne soient pas modifiables de manière concurrente, d’où leur nom d’atome. Cela correspondrait à la notion de carte Hypercard, de page web ou d’entrée dans un Wiki.

Un type particulier d’atome est la vue. Une vue est en quelque sorte une fonction. Une vue prend comme entrée un ou plusieurs objets du système pour produire un nouvel objet. Cet objet composite est virtuel et ne peut être édité directement, il faut soit éditer la vue pour changer les règles de composition soit changer les objets qui sont ses sources (ce qui revient au fait au même vu que les paramètres d’une vue sont aussi un objet).

Par exemple une vue prend un atome contenant des données tabulées et en fait un camembert. Un type particulier de vue est un aggregateur qui prend des objets pour faire un texte. Par exemple en mettant bout à bout des textes. Simplement concaténer les textes ne suffira pas, il faudra par exemple ajuster le niveau des titres – chaque objet aura des titres de niveau 1, mais dans le texte composite ces titres seront de niveau 2.

Voici quelques idées d’atomes

  • Textes
  • Données (pour graphiques)
  • Images
  • Structure de textes (outline)

Voici quelques idées de vues:

  • Transformation de texte – par exemple appliquer des transformation typographiques.
  • Aggrégation – construire un long texte à partir de textes en les assemblant selon un outline
  • Construction d’une table des matières à partir d’un outline
  • Construction d’un glossaire, d’un index
  • Expansion de macros
  • Change tracking
  • Composition d’image
  • Traduction vers différent formats

l’idée serait probablement d’avoir un système genre CVS qui gère chaque atome comme un fichier. Les vues seraient des instances de classes données. L’état de ces instances est à son tour un objet (qui peut donc venir d’une vue). Les vues probablement écrites en langage de script. La génération des objets dérivés par les vues devrait être déclenchée soit manuellement, soit automatiquement, via un outil de gestion de dépendance genre make.

7 thoughts on “À propos de plyme

  1. Alias : oui mais c’est limité au monde Mac

    Thias : ok, très bien, mais j’avoue avoir de la peine à visualiser le concept. ArgoUML ? Et pour le système “genre CVS”, je proposais SubVersion justement parce que les transactions sont atomiques… Marrant non ?

  2. Le but des atomes est surtout de pouvoir travailler avec un maximum de concurrence. Si tu as de gros objets, un outil comme SubVersion doit gérer les conflits, ce qui fout toujours le bordel. Les vues sont le truc qui manque dans un wiki, i.e quelque chose qui permette d’assembler des éléments et les transformer.

  3. Celà implique donc un système de verouillage lorsqu’une personne est en train d’éditer un atome, non ?

    Il serait donc possible d’utiliser SubVersion pour la centralisation des données et un frontale qui gère la non concurrence des modifications.

    Il me semble qu’a ce niveau, CVS ne fait pas mieux que SubVersion ?

  4. (peste, j’ai planté mon navigateur, faut tout que je reécrive)

    Bon, on prend plutôt SubVersion parce qu’intuitivement c’est ce que j’aurais utilisé pour fusionner des versions différentes de documents. Comme contrairement à CVS, SubVersion est atomique au niveau des transactions, c’est possible de savoir précisément ce qui a été modifié entre deux version.

    Maintenant cette histoire d’atome et de vue… Si je comprends bien Thias, un atome n’est qu’un bloc de données qu’on traite en une fois. Si j’ai deux version d’un même atome, normalement je devrais assurer la fusion manuellement, et c’est là qu’interviennent les vues. Les vues, finalement, sont des outils pour simplifier et organiser la fusion des modifications en fonction des types d’atomes concernés.

    Pas besoin de verouiller donc, puisque c’est concurrent : tout le monde peut modifier l’atome, mais chaque fois qu’on veut pousser une modif dans SVN, on doit d’abord fusionner avec la modif précédentes.

  5. Les atomes sont tes données brutes, par exemple, le texte sur tel ou tel sujet. Les vues sont ce qui assemble les assemble pour donner un texte.

    Par exemple, on bosse sur la Noire Essence, il y a un atome par aspect du monde, un pour le texte sur les Rynlandes, un pour la création de personnage. Il y a une vue qui met ces atomes ensemble en un texte structuré (et qui prend un atome du genre outline comme paramètre). Une autre vue lie dans ce texte les images, une troisième ajoute les références entre éléments du texte, une autre vue peut par exemple superposer du texte à une carte.
    Il y aurait une vue pour générer une version pdf du texte, une autre pour le html, une autre pour tu RTF.

Leave a Reply to ThiasCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.