Ce serait bien d'avoir une page qui classe les composants selon un nom non technique. par exemple "carte graphique" ou "Controlleur USB" avec de petites icônes, un minimum de détail ...
En fait ca y est déjà à la fin entre crochets, il faudrait juste afficher ça plus joliment. Comme ça ca permettrait a des personnes qui ne conaissent pas très bien leur hardware d'avoir une page récapitulative.
Et pourquoi pas ajouter une option pour la rendre publique au choix de l'utilisateur.
Sinon, je trouve que c'est une très bonne initiative même si je trouve que le packaging laisse à désirer. Le paquet source contient 4 fichiers avec aucun Makefile (même archi simple, je ne demande pas les autotools), aucun README pour expliquer comment compiler et installer, les dépendances ...
Du coup pour faire le paquet ArchLinux, j'utilise le src.rpm qui fournit plus d'infos. mais ce n'est pas super pratique je trouve.
Il est prévu d'ajouter un ordinateur mais pas de mettre à jour un ordinateur existant avec un nouveau rapport preovenant d'une nouvelle version du soft. On fait comment ?
Bon, apparament ça marche si on met exactement le même nom pour l'ordinateur. mais ce serait plus facile de pouvoir le faire directement sur la page de l'ordinateur.
Comme je l'ai déjà dit (mais ce n'est pas ressorti assez dans le journal) je pense qu'il faut effectivement utiliser à fond les attributs étendus. Les fichiers desc sont là uniquement pour apporter une compatibilité avec les systèmes incompatibles.
Pour ce qui est de l'évolutivité, je n'avais pas l'impression de la limiter, mais c'est vrai que c'est peut être le cas. Il faut bien comprendre que ce n'est qu'un draft que j'ai écrit hier dans la nuit car je voulais noter l'idée avant de dormir :). L'idée c'est que les headers du style X-Quelquechose ou com.example.quelquechose sont disponnible à tout le monde, les autres doivent être présents dans la norme. mais il n'est absolument pas interdit de rajouter des headers dans la norme.
En fait il faudrait peut être faire ça avec la version. Si la version du fichier est supérieure à la version du parseur, alors les headers inconnus sont ignorés et le fichier est valide.
Pour ce qui est de la RFC 2822, je me doutais bien que ce que je faisais devait déjà être plus ou moins normalisé. Cependant (je n'ai pas encore regardé la RFC) mon système permet de mettre n'importe quelle donnée *binaire* comme valeur des headers. C'est pour cela que je n'ai pas cherché la RFC... Mais c'est vrai qu'on peut toujours utiliser base64 ou autre codage si on veut.
Je pense comem toi que les attributs étendus doivent être utilisés. Ma spécification était plus dans le sens de faire bouger les choses mais il faut peut être la travailler plus effectivement.
D'ailleurs dans le draft n°2 j'en parle.
Le problème c'est que faire un spec pour dire qu'on doit utiliser tel attribut avec tel nom avec comme contenu un type MIME ou UTI, ca fait un peu brut je trouve. Et avec mon fichier spec je propose un moyen de concerver la compatibilité.
Mais c'est vrai que j'imagine mal ma spec devenir définitive, pourmoi c'est plus une base de discussion. D'ailleurs à l'intérieur je parle du Content-Type mais je préfèrerais mettre un UTI car les types MIME sont utilisés un peu à tort et à travers sans concertation. UTI permet lui à tout le monde de créer un nouvel identifiant de type sans se soucier d'éventuelles collisions.
C'est très bien mais cela demande une analyse plus complexe du fichier que ce que fait déjà libmagic. Et cela pose un problème de performances. Je ne connais pas trop mais ca m'étonnerait fort que ce ne soit pas comme ça.
Ce n'est pas tout à fait le même but.
mais peut être que le résultat de hachoir-metadata peut être stoké (en cache) dans les attributs étandus...
L'interêt est de pouvoir facilement (grâce à fuse) empaqueter des fichiers sans rien perdre. je n'ai pas d'application concrètes directement mais je trouverais ça sympa à avoir sur un desktop.
En fait je le fais en pensant aux fichiers images .dmg sur Mac OS. Suaf que c'est en lecture seule encore. Ces images sont en général utilisées pour empaqueter des applications pour Mac OS X (car une application = 1 dossier).
Bien sûr, on peut utiliser les fichiers zip mais c'est moins intuitif que fuse. Et pour ce qui est de monter une archive zip avec fuse, ce n'est pas encore ça (pas d'écriture temps réel, juste une écriture lors du démontage, et si ça échoue, l'erreur est passée sous silence et tu te retrouve avec une archive corrompue)
Mon idée n'était pas de pondre quelque chose de fonctionnel mais de proposer quelque chose pour faire bouger les choses ...
Pour ce qui est du Summary, je ne sais pas si c'est intéressant, car c'est quelque chose qui doit être rempli par l'utilisateur et qu'il ne remplira jamais si il n'a pas la discipline de le faire. En tout cas ce ne dois pas être obligatoire. mais c'est vrai que ca peut être pratique.
les crochets ca peut être pratique pour la langue mais en général quelqu'un ne va pas s'amuser a renseigner un document qu'il crée dans toutes les langues du monde. mais il faut que ce soit permis, c'est vrai.
Pour ce qui est du transfert des méta-données, c'est je pense intéressant de faire soit un conteneur comme je le décris ou d'associer un fichier avec les méta-données. Du moins tant que les protocoles ne permettent pas de spécifier tous les attriuts qu'on veut. Apple le fait déjà avec les données spotlight (je crois, pas testé) qu'il envoie avec chaque fichier attaché dans un email. Un fichier de type application/applefile. Bien sûr je ne sais pas si c'est standardisé. Mon idée c'est de faire quelque chose de similaire standard.
Mais c'est vrai que si tous les protocoles permettent de faire passer les meta-données, ce n'est plus utile du tout.
Pour ce qui est du type de contenu, je ne crois pas qu'il faille garder le content-type actuel qui est assez peu standardisé. Apple propose une alternative basée sur une notation reverse DNS qui permet a n'importe qui de créer des nouveaux types. [http://en.wikipedia.org/wiki/Uniform_Type_Identifier]
Pour ce qui est de la date, je pense que c'est intéressant de la garder. Car il y a trop de cas où elle est perdue. par exemple lorsqu'on compresse/décompresse un fichier, lorsqu'on le copie, ... la date est réinitialisée. Et du coup pas moyen de savoir quand on a bien pu écrire un fichier texte qui traine depuis toujours dans notre homedir.
Et entre .xml et .xml, tu différencie quoi ? Entre .ogg et .ogg .... et entre un .txt (iso-8859-1) et .txt (utf-8) ?
A propos des encodages des fichiers textes, j'ai souvent ce problème et en général l'autodétection est foireuse. Sauf qi j'ai un magic cookie utf-8 mais peu d'éditeurs le supportent. De plus c'est plutôt avec iso-8859-1 que j'ai des problèmes.
ouais genre "j'ai compris unix", mais pas la peine de compliquer inutilement avec ton truc.
Pas vrament, surout qu'il y a Plan9 qui s'approche de ce concept. peut être j'aurais du mettre que je préférais travailler par documents.
En disant ça je ne pensait pas a unix mais plutôt aux conceps d'Étoilé. Car le concept tout est fichier d'unix ne se place pas a ce niveau. Que peux tu faire d'un fichier device, pipe ... dans une interface graphique ? Rien.
maildir/mh ?
Oui, je l'utilise mais nautilus ne sais pas afficher mes e-mails :(
"enregistrer la page sous" ?
Et le lien vers la page il est où ?
Si c'est un commentaire dans la source ce n'est pas suffisant, je n'ai pas envie de voir la source de chacun de mes bookmarks a chaque fois que je les utilise
Cacher les extensions de fichiers serait la solution effectivement, solution si on s'accorde a rajouter un peu de longeur a ces extensions, et peut être uassi une normalisation des extensions. Mais il me semble que pas mal de personnes ici n'aiment pas ça (je peux me tromper) et quitte a développer un nouveau truc, je préfère personellement mes métadonnées.
Cacher les extensions cela revient en fait à rajouter une metadonnée ... sauf qu'on l'incluue dans le nom ... et on ne lui donne pas assez de place pour mettre assez d'infos dedans (comme l'encodage d'un fichier texte qui fait partie du type de fichier a mon avis)
L'idée c'est plutôt de mettre mon système de fichier dans un fichier qui peut grandir et diminuer à loisir en fonction des fichiers qu'il y a dedans...
Tout va peut être bien si yu aimes utiliser les extensions des fichiers pour identifier le type. Mais je trouve cette solution comme peu élégante et comme manquant de finesse car finalement une extension ce n'est pas assez. De plus je trouve que c'est moche et je préfère dans bien des cas ne pas la mettre.
Je pense que le nom de fichier doit appartenir a l'utilisateur qui dispose du fichier. Et si on met une extension (comme cela m'arrive, notament pour les fichiers sources) il faut que ce soit du choix de l'utilisateur.
je dois dire que j'ai du mal a imaginer qu'on puisse imaginer les extensions aux noms de fichier comme autre chose qu'un palliatif pour une méta-donnée inexistante.
Si ça se trouve je suis en train de rêver aux cotés des gens qui pensent sur Étoilé. mais je préfère faire quelque chose pour que ce rêve prenne forme.
Dans mon imaginaire les fichiers devraient être à la base de tout. Chaque e-mail reçu irait se loger dans un fichier qu'on pourrait directement visualiser au sein du navigateur de fichiers, chaque bookmark qu'on a vers une page web serait dans un fichier qui contiendrait aussi un cache sur la page pointée (permettant de voir ses bookmarks offline), et ainsi de suite. Et les extensions sone une gêne car elles introduisent quelque chose de technique (le type du fichier) au sein du navigateur de fichier où a mon sens on ne devrait voir que ce qui est créé par l'utilisateur. les fichiers de l'utilisateur, les noms de fichiers de l'utilisateur ...
Mon idée n'est pas de virer les extensions mais de rajouter une méta-donnée pour connaître le type d'un fichier qui permettrait de se passer des extensions là o elles sont actuellement obligatoires et où je n'en veux plus.
Avec une méta-donnée tu peux bien plus précisément identifier le type d'un fichier. Car tu n'est pas limité par l'extension qui fait généralement 3 charactères et dépasse rarement les 5 caractères.
Tu ne peux pas avoir deux fichier ~/mesvacances car un nom de fichier doit être unique :) Et si tu aime les extensions, rien ne t'empêche de les rajouter.
Mais il faut aussi permettre aux gens qui n'aiment pas les extensions de pouvoir s'en passer.
De plus je te fais remarquer qu'avec les fichiers multimédia, les extensions peuvent représenter tout et n'importe quoi. par exemple un fichier.ogg peut aussi bien représenter :
- une musique OGG/Vorbis
- un son OGG/Speex
- une vidéos OGG/Theroa/Vorbis
- et d'autre combinaisons je suppose .....
Et ça m'a joué des tours lorsque j'ai mis du ogg/speex sur mon baladeur sans comprendre pourquoi ça ne marchait pas (il ne comprend que l'ogg/vorbis)
A mon avis les extensions sont très pratique dans certains domaines (programmation, makefiles, ...) mais dans d'autres contextes on devrait pouvoir s'en passer. je veux dire que cela ne devrait pas être obligatoire.
Et si tu aimes les extensions, rien ne t'empêche de les mettre.
Et si tu ne veux pas mettre d'extensions a ton fichier opendocument (comme moi) ?
Car pourquelqu'un qui ne s'y connaît pas trop en informatique, les extensions sont un moen facile de changer le type d'un fichier et de ne plus pouvoir l'ouvrir. Bref de perdre un fichier ...
La solution ? Cacher l'extension ? Une protection ?
J'utilise Apache avec une extension dont j'ai oublié le nom et qui permet selon la configuration du navigateur de proposer un fichier dans la langue que préfère l'utilisateur. Dans ce cas là, la manière la plus simple de faire c'est d'utiliser une double extension. Et j'avais donc régulièrement des fichiers avec les extensions :
.html.fr
.html.en
.xhtml.fr
.xhtml.en
Dans ce cas la, l'extension indique non seulement le type du fichiermais aussi la langue. Et dans ce cas là tu est bien embêté lorsque ton navigateur de fichier ne prend que la dernière extension en compte (.fr ou .en) alors que c'est celle d'avant qui représente le type.
Sans compter qu'on peut vouloir mettre ce qu'on veut dans le nom de fichier et que lorsqu'on ouvre son dossier ~/Documents on peut préférer voir des fichiers sans extensions (car ça prend de la place pour rien, l'icone donne déjà cette information).
C'est comme de demander de ne pas mettre d'espaces dans les noms de fichiers. Certes en ligne de commande c'est plus pratique, mais avec une interface graphique c'est bien mieux d'avoir des espaces.
si tu déplaces le fichier, tout est concervée. Pareil pour la copie. Tout ce qui se fait sur le contenu entier ne posera aucun problème (contrairement aux attributs étendus qui peuvent être perdus, il faut faire attention).
Par contre si tu fais un vi, un grep ou autre sed, ça peut poser problème. Dans ce cas c'est sûr qu'il vaut mieux utiliser les attibuts étendus. Et je pense c'est ce qu'il faut faire sur un système qui le permet.
En fait il faut voire le fichier desc comme un conteneur au même titre que tar ou gzip (mais contrairement à eux, il n'y a ni possibilité d'agrégation de plusieurs fichiers, ni compression).
L'avantage c'est que c'est du texte et que si tu l'ouvres avec Vi tu devrais quand même t'y retrouver.
L'interêt c'est de savoir avec quel logiciel on peut ouvrir un fichier donné.
Un fichier zip, jar ou odt peut s'ouvrir avec n'importe quel utilitaire zip
Un fichier jar ou odt sont conformes à la spécification jar. Mais un utilitaier jar ne pourra pas forcément ouvrir un fichier zip quelconque (Jar est plus restrictif im me semble, sans doute un fichier manifest obligatoire).
Un fichier odt s'ouvre trs bien avec un utilitaire zip ou jar. par contre OpenOffice qui ouvre les odt ne peux pas ouvrir n'importe quel fichier zip ou jar, ça ne marchera pas.
Donc il faut un moyen de différencier des 3 fichiers, sinon lorsque tu va ouvrir un fichier zip tu risque de l'ouvrir avec OpenOffice qui va raler qu'il ne comprend rien, a moins que lorsque tu n'ouvres un fichier odt, tue ne l'ouvres avec un archiveur et tu ne comprendras pas pourle coup pourquoi tu ne vois pas ton document.
L'interêt des meta-données c'est de pouvoir faire cette différence facilement.
On a le même genre de problme avec les fichiers texte. les fichiers XML par exemple. Un fichier XML peut avoir un type très complexe (grâce aux namespaces XML) pas forcément facile a identifier.
J'ai eu un problème similaire avec un logiciel que je ne retrouve plus, oregano, qui permet de faire de la simulation électronique avec spice. le firchier était il me semble un fichier XML gzippé. Pas moyen d'associer dans mon navigateur de ficheir (nautilus) une action précise pour ce fichier sans toucher à tous les fichier gzippés. pas moyen d'ouvrir les fichiers oregano avec oregano mais garder mes archives tar.gz avec file-roller.
Pour ce qui est de séparer le Content-Type de l'encodage pourquoi pas ... Sauf que pratiquement partout (HTTP, MIME, ...) lorsqu'on veut spécifier l'encodage d'un fichier on le met après le Content-Type. Il me semble avoir même lu quelque part que cela en faisait partie.
Si tu veux tu peux remplacer mon exemple (pas très parlant il est vrai par :
Content-Type: text/plain; charset=utf-8
X-Summary: summary ...
continue across multiple lines
as many as you want
com.example.attribute: value
X-Creation-Date: 2007/07/01
This is a text file
encoded in UTF-8
Here the desc file is useful because it can specify the encoding of the text file
Ca peut être une idée de mettre les headers à la fin du fichier ... Sauf que tu détectes comment la fin du fichier ? Après les derniers \n\n ? Ca veut dire parcourir tous le fichier à la recherche de toutes les séquences \n\n et prendre la dernière. Ca me semble un peu lourd. Surtotu si ton fichier est très gros.
En fait mon idée ce n'est pas d'utiliser ça directement sur le système qui supporte déjà les attributs étandus. Ce que je pense c'est qu'il serait possible soit de mettre le contenu du fichier desc dans les attributs étandus (la méthode reste à définir).
D'autant plus que les attributs étandus sont je crois stokés dans l'inode, donc l'accès y est beaucoup plus rapide.
L'idée de ce format de fichier c'est justement de pouvoir sérialiser les atrtibuts étandus lors de transfert de fichiers et sur les systèmes/logiciels qui ne supportent pas les attributs étandus.
L'idée c'est aussi de mettre une emphase sur le type de fichier qui est a mon avis une information qu'il faudrait garder avec le fichier car les nombres magiques ne sont pas la solution a tout, et les extensions non plus.
Même si je n'ai spécifié que quelques headers, on peut en mettre autant qu'on veut, et donc sérialiser ainsi les attributs étandus dans le fichier desc.
Le fichier est inclus dans le fichier desc qui contient les méta-données. Il faut bien sûr qu'un maximum de logiciels comprennent ce format de fichier. Une autre alternative est de placer tout ça dans des attributs étandus du fichier (si c'est possible).
Si j'utilise une opération qui ne supporte pas tes desc qu'est ce qui se passe ?
Par opération, tu veux dire quoi ?
Si un logiciel ne supporte pas ce format de fichier, alors il faudra utiliser un petit utilitaire à part qu'il reste à écrire qui permet d'extraire le contenu du fichier. Un peut comme une archive, sauf qu'il n'y a ni compression, ni possibilité de mettre plusieurs fichiers à l'intérieur.
Comme de tels fichiers peuvent exister (j'y ai pensé), il suffit d'utiliser plusieurs lignes logiques. Ainsi pour représenter le fichier toto\ntata on peut écrire Filename: toto\n\ttata
Car l'espace (tabulation en l'occurence) après chaque caractère de fin de ligne est enlevée du contenu. Je ne décrit lorsque je décris le stripped content
On peut même mettre n'importe quel contenu binaire. Mais c'est vrai que ce n'est pas très clair.
Le multithread c'est prévu pour la version 0.3, non ? C'est à dire pas tout de suite quand même si je ne me trompe, il faut quand même stabiliser la version 0.2.
Sinon, ça se passera comment, car un -devant le nom du prototype ca correspond à quoi. Ca va se passer comme ça ?
Section Header
- name := PROTOTYPE;
ou comme ça ?
Section Header
- name := - PROTOTYPE;
Car la première manière a déja une signification si je ne me trompe (prototype non clonable) alors que la seconde paraît bizarre.
En tout cas, j'aprécie beaucoup la programmation agents. Dans le cas d'un projet à l'IUT j'ai eu l'occasion de faire un mini-serveur/client en Java en utilisant au maximum cette notion. En gros j'avais pas mal de thread. Le seule problème que j'ai eu c'était pour implémenter la communication entre tous ces threads, justement pour avoir cette notion d'agents.
Le riz, c'est très rapide, ça se fait en environ 5 minutes.
Alors que les pates, ca peut prendre jusqu'à 10min pour la cuisson
Bien sûr, il faut laver le riz avant et le temps de cuisson et la dose d'eau varie pour chaque riz, mais une fois qu'on trouve la bonne dose (ou que quelqu'un nous le dit) cela devient très facile.
Pour avoir de nombreuses fois perdu beaucoup de données car j'avais oublié de sauvegarder ma base de donnée MySQL, je préfère maintenant pour tous mes développements local utiliser soit SQLite, soit directement des fichiers.
[^] # Re: mise à jour d'un ordinateur
Posté par Mildred (site web personnel) . En réponse au journal Support des modules http://hardware4linux.info/. Évalué à 2.
Ce serait bien d'avoir une page qui classe les composants selon un nom non technique. par exemple "carte graphique" ou "Controlleur USB" avec de petites icônes, un minimum de détail ...
En fait ca y est déjà à la fin entre crochets, il faudrait juste afficher ça plus joliment. Comme ça ca permettrait a des personnes qui ne conaissent pas très bien leur hardware d'avoir une page récapitulative.
Et pourquoi pas ajouter une option pour la rendre publique au choix de l'utilisateur.
Sinon, je trouve que c'est une très bonne initiative même si je trouve que le packaging laisse à désirer. Le paquet source contient 4 fichiers avec aucun Makefile (même archi simple, je ne demande pas les autotools), aucun README pour expliquer comment compiler et installer, les dépendances ...
Du coup pour faire le paquet ArchLinux, j'utilise le src.rpm qui fournit plus d'infos. mais ce n'est pas super pratique je trouve.
# mise à jour d'un ordinateur
Posté par Mildred (site web personnel) . En réponse au journal Support des modules http://hardware4linux.info/. Évalué à 2.
Bon, apparament ça marche si on met exactement le même nom pour l'ordinateur. mais ce serait plus facile de pouvoir le faire directement sur la page de l'ordinateur.
# Mise à jour pour ArchLinux
Posté par Mildred (site web personnel) . En réponse au journal Support des modules http://hardware4linux.info/. Évalué à 5.
http://aur.archlinux.org/packages.php?do_Details=1&ID=11(...)
(ce serai bien de faire la même chose pour Gentoo)
[^] # Re: NIH
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Pour ce qui est de l'évolutivité, je n'avais pas l'impression de la limiter, mais c'est vrai que c'est peut être le cas. Il faut bien comprendre que ce n'est qu'un draft que j'ai écrit hier dans la nuit car je voulais noter l'idée avant de dormir :). L'idée c'est que les headers du style X-Quelquechose ou com.example.quelquechose sont disponnible à tout le monde, les autres doivent être présents dans la norme. mais il n'est absolument pas interdit de rajouter des headers dans la norme.
En fait il faudrait peut être faire ça avec la version. Si la version du fichier est supérieure à la version du parseur, alors les headers inconnus sont ignorés et le fichier est valide.
Pour ce qui est de la RFC 2822, je me doutais bien que ce que je faisais devait déjà être plus ou moins normalisé. Cependant (je n'ai pas encore regardé la RFC) mon système permet de mettre n'importe quelle donnée *binaire* comme valeur des headers. C'est pour cela que je n'ai pas cherché la RFC... Mais c'est vrai qu'on peut toujours utiliser base64 ou autre codage si on veut.
[^] # Re: Soutien
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Je pense comem toi que les attributs étendus doivent être utilisés. Ma spécification était plus dans le sens de faire bouger les choses mais il faut peut être la travailler plus effectivement.
D'ailleurs dans le draft n°2 j'en parle.
Le problème c'est que faire un spec pour dire qu'on doit utiliser tel attribut avec tel nom avec comme contenu un type MIME ou UTI, ca fait un peu brut je trouve. Et avec mon fichier spec je propose un moyen de concerver la compatibilité.
Mais c'est vrai que j'imagine mal ma spec devenir définitive, pourmoi c'est plus une base de discussion. D'ailleurs à l'intérieur je parle du Content-Type mais je préfèrerais mettre un UTI car les types MIME sont utilisés un peu à tort et à travers sans concertation. UTI permet lui à tout le monde de créer un nouvel identifiant de type sans se soucier d'éventuelles collisions.
UTI: http://en.wikipedia.org/wiki/Uniform_Type_Identifier
draft n°2: http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Desc_file(...)
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Ce n'est pas tout à fait le même but.
mais peut être que le résultat de hachoir-metadata peut être stoké (en cache) dans les attributs étandus...
[^] # Re: LVM
Posté par Mildred (site web personnel) . En réponse au message Cherche système de fichier hybride pour utiliser avec fuse. Évalué à 2.
En fait je le fais en pensant aux fichiers images .dmg sur Mac OS. Suaf que c'est en lecture seule encore. Ces images sont en général utilisées pour empaqueter des applications pour Mac OS X (car une application = 1 dossier).
Bien sûr, on peut utiliser les fichiers zip mais c'est moins intuitif que fuse. Et pour ce qui est de monter une archive zip avec fuse, ce n'est pas encore ça (pas d'écriture temps réel, juste une écriture lors du démontage, et si ça échoue, l'erreur est passée sous silence et tu te retrouve avec une archive corrompue)
[^] # Re: Nouvelles versions
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Pour ce qui est du Summary, je ne sais pas si c'est intéressant, car c'est quelque chose qui doit être rempli par l'utilisateur et qu'il ne remplira jamais si il n'a pas la discipline de le faire. En tout cas ce ne dois pas être obligatoire. mais c'est vrai que ca peut être pratique.
les crochets ca peut être pratique pour la langue mais en général quelqu'un ne va pas s'amuser a renseigner un document qu'il crée dans toutes les langues du monde. mais il faut que ce soit permis, c'est vrai.
Pour ce qui est du transfert des méta-données, c'est je pense intéressant de faire soit un conteneur comme je le décris ou d'associer un fichier avec les méta-données. Du moins tant que les protocoles ne permettent pas de spécifier tous les attriuts qu'on veut. Apple le fait déjà avec les données spotlight (je crois, pas testé) qu'il envoie avec chaque fichier attaché dans un email. Un fichier de type application/applefile. Bien sûr je ne sais pas si c'est standardisé. Mon idée c'est de faire quelque chose de similaire standard.
Mais c'est vrai que si tous les protocoles permettent de faire passer les meta-données, ce n'est plus utile du tout.
Pour ce qui est du type de contenu, je ne crois pas qu'il faille garder le content-type actuel qui est assez peu standardisé. Apple propose une alternative basée sur une notation reverse DNS qui permet a n'importe qui de créer des nouveaux types. [http://en.wikipedia.org/wiki/Uniform_Type_Identifier]
Pour ce qui est de la date, je pense que c'est intéressant de la garder. Car il y a trop de cas où elle est perdue. par exemple lorsqu'on compresse/décompresse un fichier, lorsqu'on le copie, ... la date est réinitialisée. Et du coup pas moyen de savoir quand on a bien pu écrire un fichier texte qui traine depuis toujours dans notre homedir.
[^] # Re: Nouvelles versions
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Et entre .xml et .xml, tu différencie quoi ? Entre .ogg et .ogg .... et entre un .txt (iso-8859-1) et .txt (utf-8) ?
A propos des encodages des fichiers textes, j'ai souvent ce problème et en général l'autodétection est foireuse. Sauf qi j'ai un magic cookie utf-8 mais peu d'éditeurs le supportent. De plus c'est plutôt avec iso-8859-1 que j'ai des problèmes.
Pas vrament, surout qu'il y a Plan9 qui s'approche de ce concept. peut être j'aurais du mettre que je préférais travailler par documents.
En disant ça je ne pensait pas a unix mais plutôt aux conceps d'Étoilé. Car le concept tout est fichier d'unix ne se place pas a ce niveau. Que peux tu faire d'un fichier device, pipe ... dans une interface graphique ? Rien.
Oui, je l'utilise mais nautilus ne sais pas afficher mes e-mails :(
Et le lien vers la page il est où ?
Si c'est un commentaire dans la source ce n'est pas suffisant, je n'ai pas envie de voir la source de chacun de mes bookmarks a chaque fois que je les utilise
Cacher les extensions de fichiers serait la solution effectivement, solution si on s'accorde a rajouter un peu de longeur a ces extensions, et peut être uassi une normalisation des extensions. Mais il me semble que pas mal de personnes ici n'aiment pas ça (je peux me tromper) et quitte a développer un nouveau truc, je préfère personellement mes métadonnées.
Cacher les extensions cela revient en fait à rajouter une metadonnée ... sauf qu'on l'incluue dans le nom ... et on ne lui donne pas assez de place pour mettre assez d'infos dedans (comme l'encodage d'un fichier texte qui fait partie du type de fichier a mon avis)
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
[^] # Re: LVM
Posté par Mildred (site web personnel) . En réponse au message Cherche système de fichier hybride pour utiliser avec fuse. Évalué à 2.
[^] # Re: Nouvelles versions
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Je pense que le nom de fichier doit appartenir a l'utilisateur qui dispose du fichier. Et si on met une extension (comme cela m'arrive, notament pour les fichiers sources) il faut que ce soit du choix de l'utilisateur.
je dois dire que j'ai du mal a imaginer qu'on puisse imaginer les extensions aux noms de fichier comme autre chose qu'un palliatif pour une méta-donnée inexistante.
Si ça se trouve je suis en train de rêver aux cotés des gens qui pensent sur Étoilé. mais je préfère faire quelque chose pour que ce rêve prenne forme.
Dans mon imaginaire les fichiers devraient être à la base de tout. Chaque e-mail reçu irait se loger dans un fichier qu'on pourrait directement visualiser au sein du navigateur de fichiers, chaque bookmark qu'on a vers une page web serait dans un fichier qui contiendrait aussi un cache sur la page pointée (permettant de voir ses bookmarks offline), et ainsi de suite. Et les extensions sone une gêne car elles introduisent quelque chose de technique (le type du fichier) au sein du navigateur de fichier où a mon sens on ne devrait voir que ce qui est créé par l'utilisateur. les fichiers de l'utilisateur, les noms de fichiers de l'utilisateur ...
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 1.
Avec une méta-donnée tu peux bien plus précisément identifier le type d'un fichier. Car tu n'est pas limité par l'extension qui fait généralement 3 charactères et dépasse rarement les 5 caractères.
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Mais il faut aussi permettre aux gens qui n'aiment pas les extensions de pouvoir s'en passer.
De plus je te fais remarquer qu'avec les fichiers multimédia, les extensions peuvent représenter tout et n'importe quoi. par exemple un fichier.ogg peut aussi bien représenter :
- une musique OGG/Vorbis
- un son OGG/Speex
- une vidéos OGG/Theroa/Vorbis
- et d'autre combinaisons je suppose .....
Et ça m'a joué des tours lorsque j'ai mis du ogg/speex sur mon baladeur sans comprendre pourquoi ça ne marchait pas (il ne comprend que l'ogg/vorbis)
A mon avis les extensions sont très pratique dans certains domaines (programmation, makefiles, ...) mais dans d'autres contextes on devrait pouvoir s'en passer. je veux dire que cela ne devrait pas être obligatoire.
Et si tu aimes les extensions, rien ne t'empêche de les mettre.
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 3.
Car pourquelqu'un qui ne s'y connaît pas trop en informatique, les extensions sont un moen facile de changer le type d'un fichier et de ne plus pouvoir l'ouvrir. Bref de perdre un fichier ...
La solution ? Cacher l'extension ? Une protection ?
J'utilise Apache avec une extension dont j'ai oublié le nom et qui permet selon la configuration du navigateur de proposer un fichier dans la langue que préfère l'utilisateur. Dans ce cas là, la manière la plus simple de faire c'est d'utiliser une double extension. Et j'avais donc régulièrement des fichiers avec les extensions :
.html.fr
.html.en
.xhtml.fr
.xhtml.en
Dans ce cas la, l'extension indique non seulement le type du fichiermais aussi la langue. Et dans ce cas là tu est bien embêté lorsque ton navigateur de fichier ne prend que la dernière extension en compte (.fr ou .en) alors que c'est celle d'avant qui représente le type.
Sans compter qu'on peut vouloir mettre ce qu'on veut dans le nom de fichier et que lorsqu'on ouvre son dossier ~/Documents on peut préférer voir des fichiers sans extensions (car ça prend de la place pour rien, l'icone donne déjà cette information).
C'est comme de demander de ne pas mettre d'espaces dans les noms de fichiers. Certes en ligne de commande c'est plus pratique, mais avec une interface graphique c'est bien mieux d'avoir des espaces.
[^] # Re: ...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Par contre si tu fais un vi, un grep ou autre sed, ça peut poser problème. Dans ce cas c'est sûr qu'il vaut mieux utiliser les attibuts étendus. Et je pense c'est ce qu'il faut faire sur un système qui le permet.
En fait il faut voire le fichier desc comme un conteneur au même titre que tar ou gzip (mais contrairement à eux, il n'y a ni possibilité d'agrégation de plusieurs fichiers, ni compression).
L'avantage c'est que c'est du texte et que si tu l'ouvres avec Vi tu devrais quand même t'y retrouver.
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 3.
Un fichier zip, jar ou odt peut s'ouvrir avec n'importe quel utilitaire zip
Un fichier jar ou odt sont conformes à la spécification jar. Mais un utilitaier jar ne pourra pas forcément ouvrir un fichier zip quelconque (Jar est plus restrictif im me semble, sans doute un fichier manifest obligatoire).
Un fichier odt s'ouvre trs bien avec un utilitaire zip ou jar. par contre OpenOffice qui ouvre les odt ne peux pas ouvrir n'importe quel fichier zip ou jar, ça ne marchera pas.
Donc il faut un moyen de différencier des 3 fichiers, sinon lorsque tu va ouvrir un fichier zip tu risque de l'ouvrir avec OpenOffice qui va raler qu'il ne comprend rien, a moins que lorsque tu n'ouvres un fichier odt, tue ne l'ouvres avec un archiveur et tu ne comprendras pas pourle coup pourquoi tu ne vois pas ton document.
L'interêt des meta-données c'est de pouvoir faire cette différence facilement.
On a le même genre de problme avec les fichiers texte. les fichiers XML par exemple. Un fichier XML peut avoir un type très complexe (grâce aux namespaces XML) pas forcément facile a identifier.
J'ai eu un problème similaire avec un logiciel que je ne retrouve plus, oregano, qui permet de faire de la simulation électronique avec spice. le firchier était il me semble un fichier XML gzippé. Pas moyen d'associer dans mon navigateur de ficheir (nautilus) une action précise pour ce fichier sans toucher à tous les fichier gzippés. pas moyen d'ouvrir les fichiers oregano avec oregano mais garder mes archives tar.gz avec file-roller.
# Nouvelles versions
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 1.
http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Desc_file(...)
la version draft 2:
http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Desc_file(...)
[^] # Re: Moué
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 3.
Pour ce qui est de séparer le Content-Type de l'encodage pourquoi pas ... Sauf que pratiquement partout (HTTP, MIME, ...) lorsqu'on veut spécifier l'encodage d'un fichier on le met après le Content-Type. Il me semble avoir même lu quelque part que cela en faisait partie.
Si tu veux tu peux remplacer mon exemple (pas très parlant il est vrai par :
Ca peut être une idée de mettre les headers à la fin du fichier ... Sauf que tu détectes comment la fin du fichier ? Après les derniers \n\n ? Ca veut dire parcourir tous le fichier à la recherche de toutes les séquences \n\n et prendre la dernière. Ca me semble un peu lourd. Surtotu si ton fichier est très gros.
[^] # Re: Moué
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
D'autant plus que les attributs étandus sont je crois stokés dans l'inode, donc l'accès y est beaucoup plus rapide.
L'idée de ce format de fichier c'est justement de pouvoir sérialiser les atrtibuts étandus lors de transfert de fichiers et sur les systèmes/logiciels qui ne supportent pas les attributs étandus.
L'idée c'est aussi de mettre une emphase sur le type de fichier qui est a mon avis une information qu'il faudrait garder avec le fichier car les nombres magiques ne sont pas la solution a tout, et les extensions non plus.
Même si je n'ai spécifié que quelques headers, on peut en mettre autant qu'on veut, et donc sérialiser ainsi les attributs étandus dans le fichier desc.
[^] # Re: ...
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 1.
Le fichier est inclus dans le fichier desc qui contient les méta-données. Il faut bien sûr qu'un maximum de logiciels comprennent ce format de fichier. Une autre alternative est de placer tout ça dans des attributs étandus du fichier (si c'est possible).
Par opération, tu veux dire quoi ?
Si un logiciel ne supporte pas ce format de fichier, alors il faudra utiliser un petit utilitaire à part qu'il reste à écrire qui permet d'extraire le contenu du fichier. Un peut comme une archive, sauf qu'il n'y a ni compression, ni possibilité de mettre plusieurs fichiers à l'intérieur.
Ou alors on patche le logiciel.
[^] # Re: ..
Posté par Mildred (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 1.
Car l'espace (tabulation en l'occurence) après chaque caractère de fin de ligne est enlevée du contenu. Je ne décrit lorsque je décris le stripped content
On peut même mettre n'importe quel contenu binaire. Mais c'est vrai que ce n'est pas très clair.
# En Lisaac
Posté par Mildred (site web personnel) . En réponse au journal Les processeurs multicoeurs et l'avenir du développement. Évalué à 2.
Sinon, ça se passera comment, car un -devant le nom du prototype ca correspond à quoi. Ca va se passer comme ça ?
Section Header
- name := PROTOTYPE;
ou comme ça ?
Section Header
- name := - PROTOTYPE;
Car la première manière a déja une signification si je ne me trompe (prototype non clonable) alors que la seconde paraît bizarre.
En tout cas, j'aprécie beaucoup la programmation agents. Dans le cas d'un projet à l'IUT j'ai eu l'occasion de faire un mini-serveur/client en Java en utilisant au maximum cette notion. En gros j'avais pas mal de thread. Le seule problème que j'ai eu c'était pour implémenter la communication entre tous ces threads, justement pour avoir cette notion d'agents.
[^] # Re: Le soir
Posté par Mildred (site web personnel) . En réponse au journal La nourriture des DLFPiens. Évalué à 2.
Alors que les pates, ca peut prendre jusqu'à 10min pour la cuisson
Bien sûr, il faut laver le riz avant et le temps de cuisson et la dose d'eau varie pour chaque riz, mais une fois qu'on trouve la bonne dose (ou que quelqu'un nous le dit) cela devient très facile.
[^] # Re: Avec PHP5 ?
Posté par Mildred (site web personnel) . En réponse à la dépêche SQLite 3.4.0 est sorti. Évalué à 2.
J'aime bien SQLite.