Est-ce que cette limitation est d'ordre technique sur le format de fichier choisi ? ou une contrainte choisie pour optimiser ?
Si tu parles de Jubako quand tu dis format de fichier, c'est moi qui l'ai créé, donc on peut pas vraiment parler de contrainte :)
En fait ce n'est pas facile de créer des formats de fichier modifiables. Quand t'y pense, même un simple fichier texte est rarement modifier. En général il est recréer. Et c'est compréhensible, si tu rajoutes un caractère en plein milieu, ça veut dire que tu dois décaler la deuxième partie du fichier, donc réécrire la moitié du fichier. C'est bien plus simple de considéré le fichier comme "recréable" plutôt que comme modifiable.
De même au niveau de l'implémentation. Si tu considères ton conteneur comme non modifiable ça simplifie grandement le code. Tu peux mettre en place du cache ou du multithreading bien plus facilement que si tu dois gérer des potentielles modifications concurrentes.
Pareil pour la création, c'est plus simple d'implémenté un créateur qui prend du contenu et l'écrit dans un fichier sans se poser la question de fournir un accès en lecture performant sur ce même contenu.
Mais Jubako permettrait de créer des conteneurs facilement recréable grâce au concept de Pack. Si tu as une archive avec N contentPacks, tu peux créer un N+1ieme pack qui contient ton contenu à rajouter et tu refais seulement le directoryPack pour rajouter un entrée qui pointe vers ton nouveau contenu. (Ou tu fais pointer une entrée existante)
On peut même aller un peu plus en considérant que le N+1 pack est celui qui contient les modifications et qu'on recrée ce pack à chaque fois.
J'envisage même de potentiellement créer un "sous-format" de type "Overlay" pour standardiser ça.
J'imaginais aussi pouvoir faire packager un projet musical, tout en ayant la possibilité d'aller le modifier une fois monté. L'essentiel des accès sont en lecture, mais quelques modification pourraient encore être faites niveau métadonnées par exemple.
Dans ton cas tu pourrais stocker les métadonnées soit sous la forme de propriétés des entrées soit comme deuxième contenu associé aux entrées (mais stocker dans un pack différent que tes données). Quand tu modifies les métadonnées, tu ne modifie que le directoryPack (dans le premier cas) ou que le pack de métadonnées (et si tu te débrouille bien, tu n'as pas à recréer le directoryPack).
Mais niveau implémentation, on est encore loin de tout ça. C'est que le début :)
[^] # Re: Bravo !
Posté par GaMa (site web personnel) . En réponse à la dépêche Jubako et Arx, un conteneur universel et son format d’archive. Évalué à 7.
Si tu parles de Jubako quand tu dis format de fichier, c'est moi qui l'ai créé, donc on peut pas vraiment parler de contrainte :)
En fait ce n'est pas facile de créer des formats de fichier modifiables. Quand t'y pense, même un simple fichier texte est rarement modifier. En général il est recréer. Et c'est compréhensible, si tu rajoutes un caractère en plein milieu, ça veut dire que tu dois décaler la deuxième partie du fichier, donc réécrire la moitié du fichier. C'est bien plus simple de considéré le fichier comme "recréable" plutôt que comme modifiable.
De même au niveau de l'implémentation. Si tu considères ton conteneur comme non modifiable ça simplifie grandement le code. Tu peux mettre en place du cache ou du multithreading bien plus facilement que si tu dois gérer des potentielles modifications concurrentes.
Pareil pour la création, c'est plus simple d'implémenté un créateur qui prend du contenu et l'écrit dans un fichier sans se poser la question de fournir un accès en lecture performant sur ce même contenu.
Mais Jubako permettrait de créer des conteneurs facilement recréable grâce au concept de Pack. Si tu as une archive avec
NcontentPacks, tu peux créer unN+1ieme pack qui contient ton contenu à rajouter et tu refais seulement le directoryPack pour rajouter un entrée qui pointe vers ton nouveau contenu. (Ou tu fais pointer une entrée existante)On peut même aller un peu plus en considérant que le
N+1pack est celui qui contient les modifications et qu'on recrée ce pack à chaque fois.J'envisage même de potentiellement créer un "sous-format" de type "Overlay" pour standardiser ça.
Dans ton cas tu pourrais stocker les métadonnées soit sous la forme de propriétés des entrées soit comme deuxième contenu associé aux entrées (mais stocker dans un pack différent que tes données). Quand tu modifies les métadonnées, tu ne modifie que le directoryPack (dans le premier cas) ou que le pack de métadonnées (et si tu te débrouille bien, tu n'as pas à recréer le directoryPack).
Mais niveau implémentation, on est encore loin de tout ça. C'est que le début :)
Matthieu Gautier|irc:starmad