Une nouvelle manière de stocker ses données : GLScube

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
17
juil.
2006
Linux
GLSCube (pour GNU/Linux Semantic Storage System) est un pseudo système de fichiers permettant de gérer des fichiers en fonction de tags plutôt que par la classique méthode arborescente. L’intérêt est de ne plus avoir à se rappeler où est stocké tel ou tel fichier, mais simplement ce qu’il contient.

Dans ce but, GLSCube est capable d’extraire un certain nombre de données des fichiers qu’il manipule, mais permet aussi à l’utilisateur de définir ses propres attributs.

GLScube est utilisable en “espace utilisateur” via FUSE.

Il est sous licence GPL. Les systèmes de fichiers (abrégé en SF par la suite) classiques se contentent de stocker les fichiers comme étant des paquets d’octets, sans se poser plus de questions sur leur contenu. À l’inverse, GLScube disposent d’importateurs pouvant extraire puis indexer les informations pertinentes des fichiers en fonction du type de ceux-ci, afin de les mettre à disposition de l’utilisateur ou du développeur.

Par exemple, GLScube pourra extraire d’un MP3 le nom du groupe, du morceau, sa longueur, etc. Bien entendu, l’intérêt de GLScube n’est pas dans ces possibilités d’extraction, mais dans la façon dont ces données sont rendus accessibles à l’utilisateur. Celui ci peut ainsi chercher toutes les chansons de Brassens de plus de 3 minutes, ou les images de 600 pixels, etc.

En outre, GLScube permet à l’utilisateur de tagguer lui même ses documents. Il peut ainsi leur ajouter ses propres mots-clefs. Par ailleurs, il est également possible d’établir des liens entre les documents.

Par analogie avec les répertoires des SF classiques, GLScube dispose de répertoires virtuels. Ceux ci, au lieu d’être associé à l’ensemble des fichiers qu’ils contiendraient, sont en fait associés à une requête, et représentent donc le résultat de la requête. Ainsi, on peut avoir un “répertoire” permettant d’accéder à l’ensemble des fichiers audio d’une durée de 2’10 ainsi qu’à l’ensemble des fichiers portant le tag “Musique Classique”, ce qui peut aussi bien comprendre des fichiers audio que des documents textes, HTML, etc. Bien entendu, comme dans un SF classique, il est possible de hiérarchiser ces répertoires virtuels.

Aujourd’hui, GLScube est capable de “comprendre” les types de fichiers suivants : OpenOffice Calc, OpenOffice Impress, OpenOffice Writer, PDF, JPEG, WAV, MP3 and AVI.

GLScube fournit aux développeurs une API leur fournissant les services nécessaires pour que leurs fichiers soient utilisables par GLSCube.
GLScube est encore en plein développement, et il reste bon nombre de fonctions à implanter. Citons entre autre :
  • Intégration d’un mécanisme de transaction pour les requêtes associées aux répertoires virtuels;
  • Support de plus de types de fichiers. En particulier, les prochains fichiers supporté seront de type BMP, PNG, RealAudio, RealVideo, Quicktime, OGG, MS Word, MS Powerpoint et MS Excel;
  • Ajout d’une fonctionnalité Rechercher/Remplacer sur les mots clefs;
  • Requête dynamique : lorsque qu’une application cliente utilisant l’API de GLScube effectue une requête sur le SF, et si des fichiers sont ajoutés/modifiées pendant ce temps, l’application sera notifiée en temps réel du changement de résultat de la requête;

D’un point de vue plus technique, GLScube est écrit en C++ avec une large utilisation de la STL. Il est compilable avec GCC et utilise les autotools. Il est implémenté dans l’espace utilisateur via FUSE. Il est à noter que ce n’est qu’une surcouche au SF réel : GLScube ne s’occupe pas du tout de l’organisation des données sur le disque. En revanche, il fournit un pseudo système de fichier pour permettre aux applications qui n’ont pas été écrites spécifiquement pour GLScube de tout de même pouvoir l’utiliser.

Aller plus loin

  • # Encore une alternative à gougueule desktop ?

    Posté par  . Évalué à 0.

    "Organize/Search/Develop", les trois mêmes piliers sur lesquels se repose google pour nous refiler son google desktop.
    Même si le ciblage a le mérite d'être clair, GLScube a l'air moins efficace au niveau compatibilité que ses modèles (Beagle, Kat, Google Desktop) car il ne gère pas (encore) les formats propriétaires, dommage ...
    • [^] # Re: Encore une alternative à gougueule desktop ?

      Posté par  . Évalué à 6.

      Oui, mais tu ne sembles pas compter sur la force qui a fait le logiciel libre: le partage. Des plugins pour des formats propriétaires sont en cours de développement, et je ne doute pas que d'autres personnes s'atteleront a la fourniture de beaucoup plus de plugins. Il suffit juste d'etre un peu patient (ou de contribuer :P )

      Personnellement, c'est la premiere fois que j'entends parler de ce projet, et il me semble très prometteur. la seule chose qui me chifonne c'est de savoir si ce système de fichier tient la charge avec les disque durs actuels, remplit de dizaines de gigaoctets de fichiers (au lieu de quelques megaoctets); notamment avec la fonctionnalité de recherche au fil de la frappe (traduction approximative de As-You-Type search).
    • [^] # Re: Encore une alternative à gougueule desktop ?

      Posté par  . Évalué à 3.

      C'est un brin trollesque comme commentaire :
      - le support des autres plugins n'est pas un problème si le projet marche comme le dis le commentaire plus haut.
      - GLScube permet de rendre accessible les fonctionnalités à tous les programmes (compatible ou non) grâce à son FS. Cf le PDF : Google Desktop est conçu pour répondre rapidement à une requête pas pour structurer ses documents.
  • # D'autres systèmes

    Posté par  (site web personnel) . Évalué à 3.

    Il existe aussi[1] :

    Tracker http://freedesktop.org/wiki/Software/Tracker
    Beagle http://beaglewiki.org/Main_Page
    Strigi http://strigi.sourceforge.net/index.php/Main_Page

    Ce sont vraiment des développement intéressants. Je me dis que nos applications webs pourraient bien profiter de ces fonctionnalités dans un futur proche... particulièrement l'utilisation des attributs étendus du système de fichiers.

    [1] liens trouvés sur http://freedesktop.org/wiki/Standards_2fshared_2dfilemetadat(...)
    • [^] # Re: D'autres systèmes

      Posté par  (site web personnel) . Évalué à 2.

      Les devs d'Ubuntu se posaient justement la question d'intégrer tracker car il ne prenait pas trop de ressources (en tout cas cela est incomparable par rapport à Beagle par exemple).

      Personellement je n'ai pas vraiment saisi l'engouement et l'interet de ce genre de technos : je range mes fichiers à la main dans des repertoires bien defini, mon lecteur de musique me permet si je le veut de trier ma musique, et je ne voit pas l'utilité d'une couche supplementaire pour faire cela.
      • [^] # Re: D'autres systèmes

        Posté par  . Évalué à 6.

        sauf quand tu as quelques centaines/milliers de fichiers et que tu veux sortir , par exemples si ce sont des photos, tous ceux qui ont été pris avec une vitesse < à 1/2 secondes
        Bon perso je me suis déja fait a la 'main' ma bd avec toutes les infos exifs de mes photos pour faires des stats toussa mais bon ;)
      • [^] # Re: D'autres systèmes

        Posté par  (site web personnel) . Évalué à 5.

        Il faut remettre la techno dans le contexte général des méta données et du comment les stocker et faire une recherche dessus.

        Le très grand intérêt est de ne pas avoir à implémenter à chaque fois la même chose dans chaque application. On se retrouve avec une manière standard de stocker/rechercher les méta données. On peut ainsi imaginer que les "tags" que tu as dans f-spot puissent être utilisés aussi dans d'autres applications. Que par exemple quand tu "mets à la poubelle" un fichier il garde trace d'où il vient pour pouvoir le "restaurer".

        Le problème d'aujourd'hui est le manque d'intégration transparente de ces informations. Pousser cela au niveau du système de fichiers permet de standardiser l'accès à ces infos. Et les standards pour l'accès et le stockage de l'info, c'est bon.

        Ce sont ces petites briques qui vont transformer le desktop. Un peu HS, voici un post intéressant à lire : http://www.jonobacon.org/?p=710
      • [^] # Re: D'autres systèmes

        Posté par  . Évalué à 10.

        Voilà un cas pratique:
        je viens de faire passer un festival de théâtre sous Linux. Ils ont 19 gigas de données partagées, plus les emails (quelques centaines par jour). C'est essentiellement du texte (OpenOffice) et quelques milliers de photos. 3 personnes accèdent à ces données.
        Ca va à peu près, tant qu'on se rappelle ce qu'il y a dans les données. Parce que c'est pas tout de ranger et de bien nommer (et sur 19 gigas il y a bien 5 gigas de bordel), ça n'indique pas vraiment ce que contiennent les fichiers.
        Autre exemple: il y a les emails envoyés par les compagnies de théâtre, les sites web qu'on visite, le programme du festival, ... c'est à dire des documents qu'il faut souvent relier à d'autres, plus vieux.
        Et encore un: d'ici 4 ans, 2 des 3 personnes seront parties. Comment tout retrouver ?

        Bref, autant de cas, où "ce genre de technos" serait très utiles. C'est sûr qu'on a de la cervelle en réserve, et qu'on est à peu près capable de s'y retrouver dans notre bazar, mais c'est le nôtre justement. Dans une équipe, c'est complètement différent.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: D'autres systèmes

          Posté par  (site web personnel) . Évalué à 3.

          ok, la je vois mieux...
          Mais pour un utilisateur plus basique j'avoue que cela ne m'as pas plus convaincu, à part peut-etre l'aspect "metadonnées accessibles à tout le système" mais pour arriver à une telle intégration je pense qu'il faudrait à ce moment la tout intégrer au fs, et éviter de stocker les metadonnées dans les fichiers directement (id3, exif ne feraient-ils pas doublon ?)
          • [^] # Re: D'autres systèmes

            Posté par  (site web personnel) . Évalué à 7.

            je pense qu'il faudrait à ce moment la tout intégrer au fs, et éviter de stocker les metadonnées dans les fichiers directement (id3, exif ne feraient-ils pas doublon ?)

            J'ai surement pas compris quelque chose dans cette phrase.
            AMHA, il faut faire la difference entre les données intrinsèques au fichier, et les données de l'utilisateur sur le fichier.

            Je m'explique :
            L'exif d'une photo, generalement, on trouve de base les informations suivantes : date de prise de vue, resolution de l'image, modele de l'appareil photo etc ...
            Quelque soit la personne qui consulte l'image, ces données sont réelles, et permettent de definir l'image en elle meme.
            Maintenant, tu as des "utilisateurs" de cette photo qui vont lui appliquer des tags. Ceux-ci seront plus subjectifs : par exemple, admettons qu'on aie une photo de l'arc de triomphe, pour certain cela rappellera les vacances de l'ete 2006, tandis que d'autres classeront ca dans une categorie "Monuments", et encore d'autre "la vue depuis la fenetre de mon appartement"
            Donc, autant l'exif de la photo restera valable quelque soit l'utilisateur, autant le reste est lié a ce dernier.

            On retrouve tres bien ce phenomene avec les gestionnaires de collections de fichiers mulitmedias a la itunes ou amarok : les id3tags sont contenus dans les fichiers et dupliqués dans la base de donnée.
            Par contre, d'autres informations (emplacement, nombre de fois joué, date ajout, date modification, note fournie etc ... ) sont specifique a l'utilisateur sur son pc, et ne sont donc contenus que dans la BDD.

            Donc, oui, AMHA il faut que les doublons reste. Ca fait de la redondance d'information mais c'est le plus logique egalement.
            • [^] # Re: D'autres systèmes

              Posté par  . Évalué à 4.

              Ces raisonnements sont valables si les systèmes de transfert de fichiers gèrent pas les tags (c'est sans doute pas demain la veille).

              Sinon on peux imaginer un système de tags transférés ou pas. Cela dit, un autre avantage des tags à l'intérieur du fichier c'est qu'ils sont standardisés et que chaque appli va pas s'amuser à réinventer la roue avec des noms différents.

              Une utilisation à laquelle j'ai pensé récemment : les blind tests. On peux rajouter à des morceaux le tag bt, catégorie machin, ... et retrouver le bt en question en un rien de temps, ou encore retrouver les morceaux qui sont pas encore passés en blind test, etc.

              En bref, pour ceux qui en voient pas l'intérêt, c'est comme pour pleins de trucs : on en imagine pas trop l'intérêt avant d'avoir cherché à les utiliser, ca débride l'imagination ;)
              • [^] # Re: D'autres systèmes

                Posté par  . Évalué à 4.

                Cela dit, un autre avantage des tags à l'intérieur du fichier c'est qu'ils sont standardisés et que chaque appli va pas s'amuser à réinventer la roue avec des noms différents.

                D'un autre cote, si tu stockes les tags a l'interieur du fichier, imagines ca :

                T'as un utilisateur qui peut lire certains repertoires, mais pas y ecrire.

                Il peut tager les fichiers pour s'y retrouver ? Si oui, si les infos sont dans le fichier, alors ca veut dire qu'il peut ajouter une quantite incalculable de donnees dans ce repertoire, remplissant la partition, essaye de tirer partie de vulnerabilites dans des softs lisant les tags, ...

                Alors que si les infos specifiques a l'utilisateur sont stockees chez cet utilisateur, la separation est claire et il ne peut causer de problemes a personne a part lui-meme.

                Il peut pas tager les fichiers qu'il n'a pas le droit d'ecrire ? Ca rend tous les scenarios de collections media read-only impossible a implementer avec une technique "tags dans le fichier".
                • [^] # Re: D'autres systèmes

                  Posté par  . Évalué à 2.

                  Pas faux, mais en fait je pensais surtout aux tags "de base" genre auteur,album,etc pour une chanson, qui varient pas trop, qui sont les mêmes pour tout le monde, et qu'on a pas a priori trop de raisons de personnaliser, sauf peut être en cas d'erreurs ou d'infos incomplètes. Mieux, ces infos permettent d'identifier de manière relativement précise le fichiers, et en ce sens en dont pas trop discociables.

                  Bien sûr, les deux systèmes sont complémentaires, mais dans le cas d'un transfert de fichier, ça permet d'assurer le trasnfert des infos minimales sur un fichier en l'absence de gestion des tags "fs" par la source, la destination ou le protocole de transfert.
                  • [^] # Re: D'autres systèmes

                    Posté par  . Évalué à 2.

                    les deux systèmes sont complémentaires

                    c'est sûr.
                    dans le cas que j'évoquais plus haut (petite équipe), il vaut mieux des infos accessibles par tous.

                    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: D'autres systèmes

        Posté par  (site web personnel) . Évalué à 5.

        Et ben moi si , je vois l'interet, meme si il est limité.
        Pour information etant donné que j'utilise MacOSX je parlerai donc de mon experience avec spotlight, qui propose les memes services.

        Par exemple, j'ai une collection de fichiers multimédias, ceux ci sont extremement bien rangés, puisque chacun a son propre repertoire. (c'est meme fait automatiquement par d'autres logiciels)

        Par contre, je dois dire que c'est ennuyeux d'ouvrir a la main chacun des repertoires quand je veux juste avoir une liste de ces fichiers.
        Là, je fais une recherche sur la partie du nom commune, ainsi que sur le type et pof ! J'ai une liste de fichiers qui apparait.
        Effectivement par rapport a une recherche 'normale', l'interet est moindre. par contre, etant donné que c'est intégré au FS et adossé a une DB, c'est beaucoup plus rapide.

        Et c'est drolement appréciable.
        • [^] # Re: D'autres systèmes

          Posté par  . Évalué à 1.

          je fais une recherche sur la partie du nom commune
          Un peu comme un "find . -type f" dans une interface graphique ? Personnellement, je n'ai pas besoin d'avoir plus la plupart du temps.
          • [^] # Re: D'autres systèmes

            Posté par  (site web personnel) . Évalué à 2.

            La partie commune peut eventuellement etre l'extension le probleme c'est que pour un meme type de fichier il peut y en avoir plusieurs.

            .mp3 .ogg
            .png .jpeg.jpg .tiff

            à la limite tu peut te baser sur le type mime, gnomevfs-ls l'affiche.
          • [^] # Re: D'autres systèmes

            Posté par  . Évalué à 2.

            Tu oublies que "find" n'est pas vraiment optimisé pour traiter un gros volume de données. Ta recherche risque de prendre beaucoup de temps.
            • [^] # Re: D'autres systèmes

              Posté par  (site web personnel) . Évalué à 6.

              Pour faire une recherche sur des fichiers, j'utilise un locate associé à un grep, c'est quasi intantané aussi.

              Le problème c'est qu'un FS reste un arbre hiérarchique, et selon les jours, on a pas envie de chercher un fichier selon l'humeur que l'on avait pour le classer ce jour là.

              L'exemple typique est la collection de musique, je range par genre/année/nom
              année/genre/nom
              nom/année/genre

              Par exemple perso je range par nom, car c'est plus facile de lire une liste alphabétique que de se poser à priori la question, dans quel genre je l'ai rangé, ou c'est de quelle année déjà ?
              Par contre si je dois faire une soirée théme année 80, c'est à moi de faire le tri.

              Il y a plein de soft qui permettent de faire ça maintenant, ils utilisent une BDD.

              Est-ce que la notion de filesystem est toujours pertinente pour stocker les données qui de toute manière seront une suite de 0 et de 1 sur la surface du disque dur ?

              Et que penser d'un système "CVS" intégré pour versionner automatiquement les modifications (ça serait top pour le répertoire /etc) ce qui permetrait de retrouver le sens des modifications quand on est pas rogoureux et que l'on ne note pas tout dans un fichier ou un cahier !
              D'une redondance automatique des données répartis sur la surface maintenant que les HD font plusieurs centaines de giga.

              La notion de filesystem me semble bien désuéte, on la garde pour des raisons historiques et de compatibilité, mais ça reste du bas niveau au niveau conceptuel.
              • [^] # Re: D'autres systèmes

                Posté par  . Évalué à 2.

                Et que penser d'un système "CVS" intégré pour versionner automatiquement

                si le système de fichiers était une base de données on pourrait facilement remonter dans les versions non (rollback)?

                "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: D'autres systèmes

                Posté par  (site web personnel) . Évalué à 3.

                déjà possible avec bazaar-ng par exemple : http://bazaar-vcs.org/VersioningEtc
                ne te prive pas :)
                • [^] # Re: D'autres systèmes

                  Posté par  (site web personnel) . Évalué à 2.

                  ... ou SVK.
                  http://lists.debian.org/debian-devel/2005/02/msg00495.html

                  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                  • [^] # Re: D'autres systèmes

                    Posté par  (site web personnel) . Évalué à 1.

                    Je n'ai pas vu de notion "d'auto-commit" dans vos 2 exemples.

                    Je pourrais déjà mettre mon /etc sous un systéme de versionning quelconque, faire une tâche cron pour faire les comits (mais autant faire un rsync dans ce cas)

                    Il faudrait que le système de versionning soit totalement transparent (aucune modification des applications, on sauve le fichier avec vi/emacs/nano/... et c'est le FS qui fait le versionning)
                    Du coup on y accèderait uniquement quand il y a un problème, ou pour comprendre l'historique des modifications qu'on a effectué.
              • [^] # Re: D'autres systèmes

                Posté par  (site web personnel) . Évalué à 3.

                Et que penser d'un système "CVS" intégré pour versionner automatiquement les modifications
                En fait on en a déjà parlé ici notamment : http://linuxfr.org/~g78/21409.html#701990

                pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                • [^] # Re: D'autres systèmes

                  Posté par  (site web personnel) . Évalué à 1.

                  Merci pour l'info, malheureusement, il va falloir que je repartitionne mon disque pour avoir un /etc séparé.
                  • [^] # Re: D'autres systèmes

                    Posté par  (site web personnel) . Évalué à 4.

                    C'est sans doute pas une bonne idée. /etc fait partie des trucs indispensables qui sont censés faire partie de / de manière à ce que le répertoire soit accessible même si les autres partitions ne peuvent pas être montées (runlevel 1, toussa).

                    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                    • [^] # Re: D'autres systèmes

                      Posté par  (site web personnel) . Évalué à 1.

                      En fait je ne comptais pas être aussi extréme, vu que /etc n'est pas trés gros.

                      J'y réfléchirais pour la prochaine installation, si je me sens assez fou pour suivre le guide du parfait petit administrateur qui crée pleins des partitions pour chaque partie de son système :-)
                      • [^] # Re: D'autres systèmes

                        Posté par  (site web personnel) . Évalué à 2.

                        Tu peux toujours créer un un /etc minimaliste dans ton / (genre fstab, initscripts, etc...), le montage de l'autre (cvs/svn/etc) par dessus ne posera pas de problème sérieux ;)

                        Il faudra que tu génère a la main ton mkinitrd pour avoir les modules et tout ce qui va bien pour monter /etc au boot ;)
  • # API pour les nouveaux types de fichiers

    Posté par  (site web personnel) . Évalué à 2.

    Je n'ai pas trouvé sur le site où on peut trouver les informations pour développer des modules pour permettre à GLScube de gérer de nouveaux types de fichiers. Alors si c'est juste parce que je suis très fatigué aujourd'hui, j'aimerais bien que quelqu'un m'indique où ça se trouve. Merci.

    PS : Rien à voir, mais de voir pour la page d'accueil une image pour afficher la moitié du texte, ça me fait toujours bizarre... Niveau accessibilité c'est pas terrible du tout.
  • # et pour tester ?

    Posté par  (site web personnel) . Évalué à 2.

    $ cat glscube/README

    Makefiles were temporarily removed from this module due to some issues.

    Will be restored in the next commit.
    C'est pratique :(

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

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