> Oui mais il y a l'existant.
> Oublier cela c'est utopique
Certes, mais laisse moi être utopique un instant.
Imagines un driver de FS qui fasse que quand on écrit un fichier sous /photo/vacances/2005/ ça écrive simplement un fichier en l'associant aux catégories photo, vacances et 2005 ?
Imagines que quand j'essaye de le relire, entrer dansle répertoire vacance me rend disponnible dans ce répertoire tous les fichiers sous la catégorie "vacance", que si je rentre dans /vacance/2005 ça me sélectionne les fichiers dispo sous vacance et sous 2005 ?
Il y a certainement d'autres problèmes à voir mais techniquement ça résoud une bonne dose de compatibilité. Si on réserve ce type de FS aux docs utilisateurs (il ne s'agit pas forcément de changer tout le système qui marche déjà) ça peut être faisable.
> Note 1 : d'ailleurs tout les systèmes de moteurs de recherche intégré à l'OS
> repose sur un filesystem "classique".
Pour l'instant, pour l'instant. Avec ce genre de phrases on n'avancera jamais.
Ceci dit rien n'empêche de faire mon joli système avec un "vrai" FS comme backend derrière.
Dans la démarche "moteur de recherche" on a Beagle qui pousse. C'est un "mieux que rien" mais ça ne te permettra jamais de retrouver la photo de ta cousine : il n'y a rien qui permet de spécifier un mot clé ou une méta donnée pour qu'elle soit relue plus tard.
> Un fichier est unique. Un système par catégorie ( choisi par l'utilisateur ) ne l'ai pas.
Un fichier est unique, ses categories ou ses répertoires ne le sont pas. Je ne vois aucune différence ici entre le système avec ou sans répertoire. Encore une fois, que je fasse "vacance + 2005 + photo"/photo2002154.jpg ou /vacance/2005/photo/photo2002154.jpg lors de l'enregistrement ça ne change rien, ni pour le système ni pour l'utilisateur.
> 1) si je pense que cela reste réservé à des "power users" de part ca complexité
C'est là surtout qu'on rentre en conflit (parce que sur les problèmes de compatibilité ou de développement je suis d'accord qu'il faudra du boulot). Pour moi le concept même d'un entrepot hiérarchique *est* complexe à terme. Il suffit de prendre n'importe quel néophyte ramer pour retrouver ses fichiers et avoir plein de versions à plein d'endroits différents. Et même moi qui commence à avoir trop de fichiers, je galère régulièrement avec le système des dossiers.
Donner des mots clés me semble toujours plus simple que donner un chemin, au pire c'est équivalent (si tu fais une bijection répertoire-mot clé).
> Que les logiciels qui font cela de façon générique
Oui, mais là où je suis d'accord avec l'auteur de la news c'est que ... c'est au FS de gérer la problématique de gestion des fichiers, pas à l'applicatif. Se baser sur l'applicatif veut dire que toutes les applis ne pourront pas relire ton classement.
Ou alors tu demandes à toutes les applis d'implémenter une lib commune, et tu viens de réimplémenter un système par dessus le système, je n'en vois pas l'intérêt si ça peut être géré directement par le système de fichier.
[^] # Re: mouai
Posté par Éric (site web personnel) . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 4.
> Oublier cela c'est utopique
Certes, mais laisse moi être utopique un instant.
Imagines un driver de FS qui fasse que quand on écrit un fichier sous /photo/vacances/2005/ ça écrive simplement un fichier en l'associant aux catégories photo, vacances et 2005 ?
Imagines que quand j'essaye de le relire, entrer dansle répertoire vacance me rend disponnible dans ce répertoire tous les fichiers sous la catégorie "vacance", que si je rentre dans /vacance/2005 ça me sélectionne les fichiers dispo sous vacance et sous 2005 ?
Il y a certainement d'autres problèmes à voir mais techniquement ça résoud une bonne dose de compatibilité. Si on réserve ce type de FS aux docs utilisateurs (il ne s'agit pas forcément de changer tout le système qui marche déjà) ça peut être faisable.
> Note 1 : d'ailleurs tout les systèmes de moteurs de recherche intégré à l'OS
> repose sur un filesystem "classique".
Pour l'instant, pour l'instant. Avec ce genre de phrases on n'avancera jamais.
Ceci dit rien n'empêche de faire mon joli système avec un "vrai" FS comme backend derrière.
Dans la démarche "moteur de recherche" on a Beagle qui pousse. C'est un "mieux que rien" mais ça ne te permettra jamais de retrouver la photo de ta cousine : il n'y a rien qui permet de spécifier un mot clé ou une méta donnée pour qu'elle soit relue plus tard.
> Un fichier est unique. Un système par catégorie ( choisi par l'utilisateur ) ne l'ai pas.
Un fichier est unique, ses categories ou ses répertoires ne le sont pas. Je ne vois aucune différence ici entre le système avec ou sans répertoire. Encore une fois, que je fasse "vacance + 2005 + photo"/photo2002154.jpg ou /vacance/2005/photo/photo2002154.jpg lors de l'enregistrement ça ne change rien, ni pour le système ni pour l'utilisateur.
> 1) si je pense que cela reste réservé à des "power users" de part ca complexité
C'est là surtout qu'on rentre en conflit (parce que sur les problèmes de compatibilité ou de développement je suis d'accord qu'il faudra du boulot). Pour moi le concept même d'un entrepot hiérarchique *est* complexe à terme. Il suffit de prendre n'importe quel néophyte ramer pour retrouver ses fichiers et avoir plein de versions à plein d'endroits différents. Et même moi qui commence à avoir trop de fichiers, je galère régulièrement avec le système des dossiers.
Donner des mots clés me semble toujours plus simple que donner un chemin, au pire c'est équivalent (si tu fais une bijection répertoire-mot clé).
> Que les logiciels qui font cela de façon générique
Oui, mais là où je suis d'accord avec l'auteur de la news c'est que ... c'est au FS de gérer la problématique de gestion des fichiers, pas à l'applicatif. Se baser sur l'applicatif veut dire que toutes les applis ne pourront pas relire ton classement.
Ou alors tu demandes à toutes les applis d'implémenter une lib commune, et tu viens de réimplémenter un système par dessus le système, je n'en vois pas l'intérêt si ça peut être géré directement par le système de fichier.