Je ne comprends pas cette focalisation sur la gestion de tags, y compris dans le billet de départ.
Prenons un tel système de fichiers. On peut facilement imaginer (et un projet que j’avais suivi il y a des années — je ne me souviens plus du nom — avait une approche similaire) que :
Ça présente une arborescence classique, dans laquelle les programmes divers se retrouvent facilement.
Un mkdir toto à la racine crée implicitement un tag toto.
Déposer un fichier dans le « répertoire » toto enregistre cet objet-fichier avec le tag toto, automatiquement.
Créer un lien avec ln toto/nom1 titi/nom2 assigne implicitement le tag titi au document pointé par nom1 ou nom2, en plus du tag toto.
Évidement, ça ne répond pas à toutes les questions :
Que signifie un lien symbolique ? Vers le même FS ; vers un autre FS ?
Que se passe-t-il si on dépose à la racine du FS ? Non-classifié ?
Quid des « sous-répertoires » ? repA/repB/file serait-il simplement l’assignation du tag repA/repB au document file ?
En tout cas, ça forme une base qui me semble extrêmement simple, que l’utilisateur lambda peut utiliser aussi naturellement qu’un ext4, sans être obligé de profiter des fonctionnalités avancées.
Bon... mais... finalement, tout ceci n’est-il pas déjà réalisable avec ext4, justement ? Les liens pas symboliques peuvent aider. Il suffirait (presque) d’être organisé. Le hic, c’est les applications qui, quand elles enregistrent une modifications, créent un nouveau fichier (inode) puis suppriment l’ancien. Donc non, on n’y est pas encore, mais il ne manque pas grand chose pour que ça convienne.
[^] # Re: De l'importance de l'organisation spatiale des documents
Posté par Yves (site web personnel) . En réponse au journal Où sont les filesystems orientés DB?. Évalué à 3.
Je ne comprends pas cette focalisation sur la gestion de tags, y compris dans le billet de départ.
Prenons un tel système de fichiers. On peut facilement imaginer (et un projet que j’avais suivi il y a des années — je ne me souviens plus du nom — avait une approche similaire) que :
mkdir totoà la racine crée implicitement un tagtoto.totoenregistre cet objet-fichier avec le tagtoto, automatiquement.ln toto/nom1 titi/nom2assigne implicitement le tagtitiau document pointé par nom1 ou nom2, en plus du tagtoto.Évidement, ça ne répond pas à toutes les questions :
repA/repB/fileserait-il simplement l’assignation du tagrepA/repBau documentfile?En tout cas, ça forme une base qui me semble extrêmement simple, que l’utilisateur lambda peut utiliser aussi naturellement qu’un ext4, sans être obligé de profiter des fonctionnalités avancées.
Bon... mais... finalement, tout ceci n’est-il pas déjà réalisable avec ext4, justement ? Les liens pas symboliques peuvent aider. Il suffirait (presque) d’être organisé. Le hic, c’est les applications qui, quand elles enregistrent une modifications, créent un nouveau fichier (inode) puis suppriment l’ancien. Donc non, on n’y est pas encore, mais il ne manque pas grand chose pour que ça convienne.