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
- Page d’accueil du projet (9 clics)
- PDF (408K) avec le pourquoi et le comment du projet (4 clics)
# Encore une alternative à gougueule desktop ?
Posté par tagada tobozo . Évalué à 0.
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 djano . Évalué à 6.
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 _alex . Évalué à 3.
- 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.
[^] # Re: Encore une alternative à gougueule desktop ?
Posté par benja . Évalué à 6.
http://rlove.org/log/2006062301.html
http://www.kernel.org/pub/linux/kernel/people/rml/fuse/beagl(...)
# D'autres systèmes
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 3.
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 Jean-Philippe (site web personnel) . Évalué à 2.
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 briaeros007 . Évalué à 6.
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 Loïc d'Anterroches (site web personnel) . Évalué à 5.
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 ZeroHeure . Évalué à 10.
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 Jean-Philippe (site web personnel) . Évalué à 3.
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 Jaimé Ragnagna (site web personnel) . Évalué à 7.
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 Thomas Douillard . Évalué à 4.
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 pasBill pasGates . Évalué à 4.
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 Thomas Douillard . Évalué à 2.
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 ZeroHeure . Évalué à 2.
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 Jaimé Ragnagna (site web personnel) . Évalué à 5.
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 lezardbreton . Évalué à 1.
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 Juke (site web personnel) . Évalué à 2.
.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 lasher . Évalué à 2.
[^] # Re: D'autres systèmes
Posté par darkleon (site web personnel) . Évalué à 6.
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 ZeroHeure . Évalué à 2.
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 Mildred (site web personnel) . Évalué à 3.
ne te prive pas :)
[^] # Re: D'autres systèmes
Posté par Krunch (site web personnel) . Évalué à 2.
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 darkleon (site web personnel) . Évalué à 1.
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 Krunch (site web personnel) . Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: D'autres systèmes
Posté par darkleon (site web personnel) . Évalué à 1.
[^] # Re: D'autres systèmes
Posté par Krunch (site web personnel) . Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: D'autres systèmes
Posté par darkleon (site web personnel) . Évalué à 1.
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 Raphaël G. (site web personnel) . Évalué à 2.
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 Tian (site web personnel) . Évalué à 2.
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 Krunch (site web personnel) . Évalué à 2.
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.