Pour moi ces spécifications (comme tu veux le faire avec un conteneur) ne sont pas utilisable.
(ça va demander trop de changements majeurs)
Pour moi, au lieu de créer des fichier encapsulant tout je pense qu'il faut différencier 3-4 cas.
1 - Sur le système de fichier :
On dois spécifier le Content-Type, le Charset, le Title et le Summary.
A savoir chaque fichier créé a partir d'un programme compatible (ou sauvegardé avec a partir d'un existant) doit embarquer ces spécification.
Cela prendrais la forme :
Content-Type: text/plain
Charset: utf-8
Title[fr]: Résumé de ma todo list
Summary[fr]: Ce que je dois finir sur mon projet.\rRaphaël réveille toi si tu lis ça !\rTu as du boulot.
Ensuite on peux utilise le Content-Type pour savoir avec quoi l'ouvrir.
On peu imaginer une liste de Content-Type officielle, genre :
text/plain
text/html
application/xhtml+xml
application/xml
source/php
source/ruby
source/python
binary/elf32-little-endian
binary/elf64-little-endian
binary/win32
image/png
image/gif
image/jpg
video/mkv
video/avi
video/ogm <= pas de ogg !!!
audio/mkv
audio/mp3
audio/mp4
audio/vorbis
audio/flac
etc...
Le charset pour plus avoir de faire des opérations "magique"
Quand au titre avec la langue entre crochet permettra, faut voir si on met pas les codes du type fr_FR, puis autoriser pour une personne en fr_BE le fallback en fr_FR (et vide versa).
Ensuite cette langue dans la titre et le résumé permet de détecter si un document est mono langue ou multi-langue.
2 - le mail
Je ne sais pas exactement comment ça marche exactement dans ce cas là, mais on dois pouvoir passer comme en-tête de fichier attaché ces quelques champs.
3 - le http, ben là c'est facile, on a le Content-Type servi direct par le serveur http, on peux imaginer d'envoyer le reste automatiquement.
(en plus ça pourra peut-être être plus rapide de taper dans les matadata du fichier que de faire de la détection sur extension)
4 - en ftp, bon là je pense qu'il faudra peut-être une commande de plus.
5 - protocoles de messageries instantané
Bon il faudra mettre a jour le protocole jabber sur le transfert de fichier a ce sujet.
Pour les autres, il faudra calculer les metadata a la réception du fichier (en tout cas pour les Content-Type et Charset et mettre les champ Title: et Summary: vide)
6 - autre moyen de transfert de fichier.
Bon là j'ai pas d'idée d'autre moyen de transfert de fichier.
Après je pense qu'il es pas utile de conserver une date de création de fichier dans les metadata car le système de fichier le fait déjà non ?
Si ma conception te plais hésite pas a faire un draft ;)
Plus sérieusement je pense que ma manière de faire permettra une transition en douceur, a savoir les vieux clients y verront rien du tout, par contre les clients compatible ça marchera direct.
Ensuite il restera plus qu'a convaincre M$ et Apple de suivre ces spécifications inter-opérables de s'échanger des fichiers sans perdre les informations supplémentaires.
Quand a ce qui est des extensions de fichier, ça on s'en foutra du coup un peu, ce sera conservé quelque temps pour éviter les ambiguités.
Ensuite on peux imaginer ça devenir un point de validation de LSB, ça permetrais d'avoir ça fonctionnel a l'horizon 2009.
Pour rappel toutes les applications sauvegardant des fichiers devront être patchés ça représente un travail énorme !
(sans parler de toutes les applications web et réception de contenu web en provenance de couillon qui le respecteront pas et enverront toujours les vieux content type pourrit genre application/octet-stream)
[^] # Re: Nouvelles versions
Posté par Raphaël G. (site web personnel) . En réponse au journal Détection du format de fichier, ma solution à implémenter. Évalué à 4.
Pour moi ces spécifications (comme tu veux le faire avec un conteneur) ne sont pas utilisable.
(ça va demander trop de changements majeurs)
Pour moi, au lieu de créer des fichier encapsulant tout je pense qu'il faut différencier 3-4 cas.
1 - Sur le système de fichier :
On dois spécifier le Content-Type, le Charset, le Title et le Summary.
A savoir chaque fichier créé a partir d'un programme compatible (ou sauvegardé avec a partir d'un existant) doit embarquer ces spécification.
Cela prendrais la forme :
Content-Type: text/plain
Charset: utf-8
Title[fr]: Résumé de ma todo list
Summary[fr]: Ce que je dois finir sur mon projet.\rRaphaël réveille toi si tu lis ça !\rTu as du boulot.
Ensuite on peux utilise le Content-Type pour savoir avec quoi l'ouvrir.
On peu imaginer une liste de Content-Type officielle, genre :
text/plain
text/html
application/xhtml+xml
application/xml
source/php
source/ruby
source/python
binary/elf32-little-endian
binary/elf64-little-endian
binary/win32
image/png
image/gif
image/jpg
video/mkv
video/avi
video/ogm <= pas de ogg !!!
audio/mkv
audio/mp3
audio/mp4
audio/vorbis
audio/flac
etc...
Le charset pour plus avoir de faire des opérations "magique"
Quand au titre avec la langue entre crochet permettra, faut voir si on met pas les codes du type fr_FR, puis autoriser pour une personne en fr_BE le fallback en fr_FR (et vide versa).
Ensuite cette langue dans la titre et le résumé permet de détecter si un document est mono langue ou multi-langue.
2 - le mail
Je ne sais pas exactement comment ça marche exactement dans ce cas là, mais on dois pouvoir passer comme en-tête de fichier attaché ces quelques champs.
3 - le http, ben là c'est facile, on a le Content-Type servi direct par le serveur http, on peux imaginer d'envoyer le reste automatiquement.
(en plus ça pourra peut-être être plus rapide de taper dans les matadata du fichier que de faire de la détection sur extension)
4 - en ftp, bon là je pense qu'il faudra peut-être une commande de plus.
5 - protocoles de messageries instantané
Bon il faudra mettre a jour le protocole jabber sur le transfert de fichier a ce sujet.
Pour les autres, il faudra calculer les metadata a la réception du fichier (en tout cas pour les Content-Type et Charset et mettre les champ Title: et Summary: vide)
6 - autre moyen de transfert de fichier.
Bon là j'ai pas d'idée d'autre moyen de transfert de fichier.
Après je pense qu'il es pas utile de conserver une date de création de fichier dans les metadata car le système de fichier le fait déjà non ?
Si ma conception te plais hésite pas a faire un draft ;)
Plus sérieusement je pense que ma manière de faire permettra une transition en douceur, a savoir les vieux clients y verront rien du tout, par contre les clients compatible ça marchera direct.
Ensuite il restera plus qu'a convaincre M$ et Apple de suivre ces spécifications inter-opérables de s'échanger des fichiers sans perdre les informations supplémentaires.
Quand a ce qui est des extensions de fichier, ça on s'en foutra du coup un peu, ce sera conservé quelque temps pour éviter les ambiguités.
Ensuite on peux imaginer ça devenir un point de validation de LSB, ça permetrais d'avoir ça fonctionnel a l'horizon 2009.
Pour rappel toutes les applications sauvegardant des fichiers devront être patchés ça représente un travail énorme !
(sans parler de toutes les applications web et réception de contenu web en provenance de couillon qui le respecteront pas et enverront toujours les vieux content type pourrit genre application/octet-stream)