Un peu comme ce que faisait BeOS avec ses requêtes dynamiques en fait (que l'on pourrait qualifier d'équivalent des "vues" des SGBDR pour les systèmes de fichier).
En parlant de ça...
Il y a quelques temps, des gens (d'une ML gnustep) se posaient la question de l'utilisation des attributs étendus dans les systèmes actuels. C'est vrai que l'usage qu'en faisait BeOS était séduisant: il stockait le type MIME du fichier, l'application préférée, l'icone (en plusieurs résolutions si besoin) et diverses métadonnées liées au type du fichier (tags ID3, ...).
Seulement, si on veut transposer toutes ces jolies choses dans un système actuel, on se heurte à un problème "balot": BeOS était mono-utilisateur. Ca peut paraître stupide, mais si on applique strictement la même chose que BeOS au niveau du stockage des métadonnées dans les EAs, on fait n'importe quoi: typiquement, on peut vouloir ouvrir un fichier donné prioritairement avec une application différente de celle préférée par le propriétaire du fichier.
En gros, on peut ranger les attributs en deux catégories: ceux intrisèques au contenu du fichier (type MIME, tags ID3) qui peuvent rester en attributs étendus, et ceux qui sont liés à une vision que l'utilisateur a du fichier (application préférée, icone) qui - dans un système multi-utilisateur - ont tout intérêt à être regroupés dans une structure à part, propre à l'utilisateur.
C'est dommage, je trouvais ça mignon de stocker l'icone directement dans le fichier :)
[^] # Re: Moins violent
Posté par Larry Cow . En réponse au journal Une base de données pour /home ?. Évalué à 2.
En parlant de ça...
Il y a quelques temps, des gens (d'une ML gnustep) se posaient la question de l'utilisation des attributs étendus dans les systèmes actuels. C'est vrai que l'usage qu'en faisait BeOS était séduisant: il stockait le type MIME du fichier, l'application préférée, l'icone (en plusieurs résolutions si besoin) et diverses métadonnées liées au type du fichier (tags ID3, ...).
Seulement, si on veut transposer toutes ces jolies choses dans un système actuel, on se heurte à un problème "balot": BeOS était mono-utilisateur. Ca peut paraître stupide, mais si on applique strictement la même chose que BeOS au niveau du stockage des métadonnées dans les EAs, on fait n'importe quoi: typiquement, on peut vouloir ouvrir un fichier donné prioritairement avec une application différente de celle préférée par le propriétaire du fichier.
En gros, on peut ranger les attributs en deux catégories: ceux intrisèques au contenu du fichier (type MIME, tags ID3) qui peuvent rester en attributs étendus, et ceux qui sont liés à une vision que l'utilisateur a du fichier (application préférée, icone) qui - dans un système multi-utilisateur - ont tout intérêt à être regroupés dans une structure à part, propre à l'utilisateur.
C'est dommage, je trouvais ça mignon de stocker l'icone directement dans le fichier :)