Ya déjà pleins de systèmes de fichiers qui supportent des attributs étendus/perso/etc et autres petits trucs sympa comme les fork (NTFS ou HFS+, sur un système de fichier Linux je sais pas trop).
Malheureusement c'est vrai que les solutions existantes pour les méta données sont pas vraiment 100% compatible les unes avec les autres, mais pour faire un truc efficace et susceptible de prendre il faut commencer par étudier ce qui existe déjà et être sur que ça peut s'intégrer efficacement et simplement avec tous les systèmes, surtout quand ils sont pas prévu pour à l'origine.
En outre ton format limite l'évolutivité sans raison apparente (il faudrait au minimum prévoir la possibilité d'ajouter des headers valide d'interprétation non obligatoire dans le format que les anciennes implémentations seraient susceptible d'ignorer) et de plus le seul header spécifié vraiment important est Content-Type ce qui un peu léger à l'époque où les environnement dominant ont tous des solutions d'indexation de méta données... d'ailleurs au dela de la description du format de fichier il faudra une spécification plus importante de l'intégration à l'existant et des recommendations pour la mise en application sur de nouveaux systèmes.
Enfin, les fichiers de descriptions "inclus" me semblent peu intéressants tels que décrits ici dans la mesure ou leur content type masque celui du payload et qu'ils sont donc incompatible avec l'existant. L'idéal serait de les stocker dans un fork sur les systèmes qui supportent, sauf que de tels système mémorisent généralement déjà le content-type ou équivalent comme des grands, donc ca limite l'interet.
Enfin ton format ressemble à celui de la RFC 2822 tout en étant incompatible ce qui est plutôt génant. Il serait préférable de tout simplement référencer la RFC 2822 histoire de ne pas réinventer la roue ni obliger de réimplementer avec du nouveau code des parser et générateurs justes un poil pas pareil.
# NIH
Posté par Guillaume Knispel . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 2.
Malheureusement c'est vrai que les solutions existantes pour les méta données sont pas vraiment 100% compatible les unes avec les autres, mais pour faire un truc efficace et susceptible de prendre il faut commencer par étudier ce qui existe déjà et être sur que ça peut s'intégrer efficacement et simplement avec tous les systèmes, surtout quand ils sont pas prévu pour à l'origine.
En outre ton format limite l'évolutivité sans raison apparente (il faudrait au minimum prévoir la possibilité d'ajouter des headers valide d'interprétation non obligatoire dans le format que les anciennes implémentations seraient susceptible d'ignorer) et de plus le seul header spécifié vraiment important est Content-Type ce qui un peu léger à l'époque où les environnement dominant ont tous des solutions d'indexation de méta données... d'ailleurs au dela de la description du format de fichier il faudra une spécification plus importante de l'intégration à l'existant et des recommendations pour la mise en application sur de nouveaux systèmes.
Enfin, les fichiers de descriptions "inclus" me semblent peu intéressants tels que décrits ici dans la mesure ou leur content type masque celui du payload et qu'ils sont donc incompatible avec l'existant. L'idéal serait de les stocker dans un fork sur les systèmes qui supportent, sauf que de tels système mémorisent généralement déjà le content-type ou équivalent comme des grands, donc ca limite l'interet.
Enfin ton format ressemble à celui de la RFC 2822 tout en étant incompatible ce qui est plutôt génant. Il serait préférable de tout simplement référencer la RFC 2822 histoire de ne pas réinventer la roue ni obliger de réimplementer avec du nouveau code des parser et générateurs justes un poil pas pareil.