Introduction

Supposons que le OpenDocument et spécifiquement le format de fichier "ODP" OpenDocument Presentation, était construit autour de SQLite. Les avantages seraient les suivants :

  • Des documents plus petits
  • Des temps de fichier/enregistrement plus rapides
  • Temps de démarrage plus rapide
  • Moins de mémoire utilisée
  • Version du document
  • Une meilleure expérience utilisateur

Notez que ceci n'est qu'une expérience de pensée. Nous ne suggérons pas que OpenDocument soit modifié. Cet article n'est pas non plus une critique de la conception actuelle d'OpenDocument. Le but de cet essai est de suggérer des moyens d'améliorer les futures conceptions de format de fichier.

A propos d'OpenDocument et de la présentation OpenDocument

Le format de fichier OpenDocument est utilisé pour les applications bureautiques : traitements de texte, feuilles de calcul et présentations. Il a été conçu à l'origine pour la suite OpenOffice mais a depuis été intégré à d'autres suites d'applications bureautiques. L'application OpenOffice a été bifurquée et renommée à plusieurs reprises. L'utilisation principale d'OpenDocument par cet auteur est la construction de présentations de diapositives avec l'une ou l'autre des applications suivantes . NeoOffice sur Mac, ou LibreOffice sur Linux et Windows.

Un fichier de présentation OpenDocument ou "ODP" est une archive ZIP contenant des fichiers XML décrivant les diapositives de la présentation et des fichiers d'images distincts pour les différentes images qui font partie de la présentation. (Les fichiers de traitement de texte et de tableur OpenDocument sont structurés de manière similaire mais ne sont pas pris en compte par cet article). Le lecteur peut facilement voir le contenu d'un fichier ODP en utilisant la commande "zip -l". Par exemple, voici la sortie "zip -l" d'une présentation de 49 diapositives sur SQLite datant de 2014. SouthEast LinuxFest conférence :

Archive:  self2014odp
  Length      DateTime    Name
---------  ---------- -----   ----472014-06-2112:34   mimetype
        02014-06-2112:34   Configurations2/statusbar/02014-06-2112:34   Configurations2/accelerator/currentxml
        02014-06-2112:34   Configurations2/floater/02014-06-2112:34   Configurations2/popupmenu/02014-06-2112:34   Configurations2/progressbar/02014-06-2112:34   Configurations2/menubar/02014-06-2112:34   Configurations2/toolbar/02014-06-2112:34   Configurations2/images/Bitmaps/547022014-06-2112:34   Pictures/10000000000001F40000018C595A5A3Dpng
    462692014-06-2112:34   Pictures/100000000000012C000000A8ED96BFD9png
58 other pictures omitted130132014-06-2112:34   Pictures/10000000000000EE0000004765E03BA8png
  10050592014-06-2112:34   Pictures/10000000000004760000034223EACEFDpng
   2118312014-06-2112:34   contentxml
    461692014-06-2112:34   stylesxml
     10012014-06-2112:34   metaxml
     92912014-06-2112:34   Thumbnails/thumbnailpng
    387052014-06-2112:34   Thumbnails/thumbnailpdf
     96642014-06-2112:34   settingsxml
     97042014-06-2112:34   META-INF/manifestxml
---------                     -------1096100678 files

L'archive ZIP de l'ODP contient quatre fichiers XML différents : content.xml, styles.xml, meta.xml et settings.xml. Ces quatre fichiers définissent la disposition des diapositives, le contenu du texte et le style. Cette présentation particulière contient 62 images, allant de photos en plein écran à de minuscules icônes, chacune étant stockée dans un fichier séparé dans le dossier Pictures. Le fichier "mimetype" contient une seule ligne de texte qui dit :

application/vndoasisopendocumentpresentation

Le but des autres fichiers et dossiers est actuellement inconnu de l'auteur, mais il est probablement difficile à comprendre.

Limitations du format de présentation OpenDocument.

L'utilisation d'une archive ZIP pour encapsuler des fichiers XML plus des ressources est une approche élégante pour un format de fichier d'application. Elle est clairement supérieure à un format de fichier binaire personnalisé. Mais l'utilisation d'une base de données SQLite comme conteneur, au lieu de ZIP, serait encore plus élégante.

Une archive ZIP est fondamentalement une base de données clé/valeur, optimisée pour le cas de l'écriture unique/lecture multiple et pour un nombre relativement faible de clés distinctes (quelques centaines à quelques milliers) ayant chacune un grand BLOB comme valeur. Une archive ZIP peut être considérée comme une base de données "pile de fichiers". Cela fonctionne, mais présente quelques inconvénients par rapport à une base de données SQLite, comme suit :

  1. La mise à jour incrémentale est difficile.

    Il est difficile de mettre à jour des entrées individuelles dans une archive ZIP. Il est particulièrement difficile de mettre à jour des entrées individuelles dans une archive ZIP d'une manière qui ne détruise pas l'ensemble du document si l'ordinateur perd son alimentation et/ou se plante au milieu de la mise à jour. Il n'est pas impossible de le faire, mais c'est suffisamment difficile pour que personne ne le fasse. Au lieu de cela, chaque fois que l'utilisateur sélectionne "Fichier/Enregistrer", l'archive ZIP entière est réécrite. Par conséquent, "Fichier/Enregistrer" prend plus de temps qu'il ne le devrait, surtout sur les anciens matériels. Les machines plus récentes sont plus rapides, mais il est toujours gênant que la modification d'un seul caractère dans une présentation de 50 mégaoctets entraîne la consommation de 50 mégaoctets de la vie d'écriture finie du SSD.

  2. Le démarrage est lent.

    Pour rester dans le thème de la pile de fichiers, OpenDocument stocke tout le contenu des diapositives dans un seul gros fichier XML nommé "content.xml". LibreOffice lit et analyse ce fichier entier juste pour afficher la première diapositive. LibreOffice semble également lire toutes les images en mémoire, ce qui est logique puisque lorsque l'utilisateur clique sur "Fichier/Enregistrer", il va devoir les réécrire, même si aucune d'entre elles n'a changé. L'effet net est que le démarrage est lent. Un double-clic sur un fichier OpenDocument fait apparaître une barre de progression plutôt que la première diapositive. Il en résulte une mauvaise expérience pour l'utilisateur. La situation devient de plus en plus ennuyeuse à mesure que la taille du document augmente.

  3. Une plus grande quantité de mémoire est nécessaire.

    Parce que les archives ZIP sont optimisées pour le stockage de gros morceaux de contenu, elles encouragent un style de programmation où le document entier est lu en mémoire au démarrage, toute l'édition se fait en mémoire, puis le document entier est écrit sur le disque pendant "Fichier/Enregistrer". OpenOffice et ses descendants adoptent ce modèle.

    On pourrait dire qu'il est normal, à l'ère des ordinateurs de bureau de plusieurs gigaoctets, de lire le document entier en mémoire. Mais ce n'est pas le cas. D'une part, la quantité de mémoire utilisée dépasse largement la taille du fichier (compressé) sur le disque. Ainsi, une présentation de 50 Mo peut nécessiter 200 Mo ou plus de RAM. Ce n'est toujours pas un problème si l'on ne modifie qu'un seul document à la fois. Mais lorsqu'il travaille sur un exposé, l'auteur aura généralement 10 ou 15 présentations différentes en même temps (pour faciliter le copier/coller des diapositives d'une présentation antérieure), ce qui nécessite des gigaoctets de mémoire. Ajoutez à cela un ou deux navigateurs web ouverts et quelques autres applications de bureau, et tout à coup, le disque tourne et la machine change de place. Et même le fait de n'avoir qu'un seul document est un problème lorsqu'on travaille sur un Chromebook bon marché équipé d'Ubuntu. Utiliser moins de mémoire est toujours mieux.

  4. La récupération en cas de crash est difficile.

    Les descendants d'OpenOffice ont tendance à faire des ségrégations plus souvent que les concurrents commerciaux. Peut-être pour cette raison, les forks d'OpenOffice font des sauvegardes périodiques de leurs documents en mémoire afin que les utilisateurs ne perdent pas toutes les modifications en attente lorsque l'inévitable crash de l'application se produit. Cela provoque des pauses frustrantes dans l'application pendant les quelques secondes où chaque sauvegarde est effectuée. Après le redémarrage de l'application après une panne, l'utilisateur voit apparaître une boîte de dialogue qui le guide dans le processus de récupération. Gérer la récupération du crash de cette façon implique une logique d'application supplémentaire et constitue généralement une gêne pour l'utilisateur.

  5. Le contenu est inaccessible.

    On ne peut pas facilement visualiser, modifier ou extraire le contenu d'une présentation OpenDocument en utilisant des outils génériques. La seule façon raisonnable de visualiser ou de modifier un document OpenDocument est de l'ouvrir à l'aide d'une application spécifiquement conçue pour lire ou écrire dans OpenDocument (lire : LibreOffice ou un de ses cousins). La situation pourrait être pire. On peut extraire et visualiser des images individuelles (disons) d'une présentation en utilisant uniquement l'outil d'archivage "zip". Mais il n'est pas raisonnable d'essayer d'extraire le texte d'une diapositive. Rappelez-vous que tout le contenu est stocké dans un seul fichier "context.xml". Ce fichier est XML, c'est donc un fichier texte. Mais ce n'est pas un fichier texte qui peut être géré avec un éditeur de texte ordinaire. Pour l'exemple de présentation ci-dessus, le fichier content.xml est composé d'exactement deux lignes. La première ligne du fichier est juste :

    <?xml version="1.0" encoding="UTF-8"?>

    La deuxième ligne du fichier contient 211792 caractères de XML impénétrable. Oui, 211792 caractères sur une seule ligne. Ce fichier est un bon test de résistance pour un éditeur de texte. Heureusement, le fichier n'est pas un obscur format binaire, mais en termes d'accessibilité, il pourrait tout aussi bien être écrit en klingon.

Première amélioration : Remplacer ZIP par SQLite

Supposons qu'au lieu d'utiliser une archive ZIP pour stocker ses fichiers, OpenDocument utilise une base de données SQLite très simple avec le schéma à table unique suivant :

CREATETABLE OpenDocTree(
  filename TEXTPRIMARYKEY,-- Name of file
  filesize BIGINT,-- Size of file after decompression
  content BLOB-- Compressed file content);

Pour cette première expérience, rien d'autre concernant le format de fichier n'est modifié. OpenDocument est toujours une pile de fichiers, sauf que maintenant chaque fichier est une ligne dans une base de données SQLite plutôt qu'une entrée dans une archive ZIP. Ce simple changement n'utilise pas la puissance d'une base de données relationnelle. Malgré cela, ce changement simple montre quelques améliorations.

Étonnamment, l'utilisation de SQLite au lieu de ZIP rend le fichier de présentation plus petit. Vraiment. On pourrait penser qu'un fichier de base de données relationnelle serait plus grand qu'une archive ZIP, mais au moins dans le cas de NeoOffice, ce n'est pas le cas. Ce qui suit est une capture d'écran réelle montrant les tailles de la même présentation NeoOffice, à la fois dans son format d'archive ZIP original tel que généré par NeoOffice (self2014.odp), et tel que reconditionné en tant que base de données SQLite en utilisant l'attribut SQLAR utilitaire :

-rw-r--r--  1 drh  staff  10514994 Jun  8 14:32 self2014.odp-rw-r--r--  1 drh  staff  10464256 Jun  8 14:37 self2014.sqlar-rw-r--r--  1 drh  staff  10416644 Jun  8 14:40 zip.odp

Le fichier de la base de données SQLite ("self2014.sqlar") est environ un demi pour cent plus petit que le fichier ODP équivalent ! Comment cela peut-il être possible ? Apparemment, la logique du générateur d'archives ZIP dans NeoOffice n'est pas aussi efficace qu'elle pourrait l'être, car lorsque la même pile de fichiers est recompressée en utilisant l'utilitaire "zip" en ligne de commande, on obtient un fichier ("zip.odp") qui est encore plus petit, d'un autre demi pourcent, comme on le voit dans la troisième ligne ci-dessus. Ainsi, une archive ZIP bien écrite peut être légèrement plus petite que la base de données SQLite équivalente, comme on peut s'y attendre. Mais la différence est minime. Ce qu'il faut retenir, c'est qu'une base de données SQLite est compétitive en termes de taille par rapport à une archive ZIP.

L'autre avantage de l'utilisation de SQLite à la place de ZIP est que le document peut maintenant être mis à jour de manière incrémentielle, sans risque de corrompre le document si une coupure de courant ou un autre crash survient au milieu de la mise à jour. (Rappelez-vous que les écritures dans les bases de données SQLite sont atomiques.) Il est vrai que tout le contenu est toujours conservé dans un seul gros fichier XML ("content.xml") qui doit être complètement réécrit si un seul caractère change. Mais avec SQLite, seul ce fichier doit être modifié. Les 77 autres fichiers du référentiel peuvent rester inchangés. Ils n'ont pas tous besoin d'être réécrits, ce qui permet à son tour à "File/Save" de fonctionner beaucoup plus rapidement et d'économiser l'usure des SSD.

Deuxième amélioration : Diviser le contenu en plus petits morceaux.

Une pile de fichiers encourage le contenu à être stocké en quelques gros morceaux. Dans le cas de l'ODP, il y a juste quatre fichiers XML qui définissent la mise en page de toutes les diapositives d'une présentation. Une base de données SQLite permet de stocker des informations en quelques gros morceaux, mais SQLite est également adepte et efficace pour stocker des informations en de nombreux petits morceaux.

Ainsi donc, au lieu de stocker tout le contenu de toutes les diapositives dans un seul fichier XML surdimensionné ("content.xml"), supposons qu'il y ait une table distincte pour stocker le contenu de chaque diapositive séparément. Le schéma de la table pourrait ressembler à quelque chose comme ceci :

CREATETABLE slide(
  pageNumber INTEGER,-- The slide page number
  slideContent TEXT-- Slide content as XML or JSON);CREATEINDEX slide_pgnum ON slide(pageNumber);-- Optional

Le contenu de chaque diapositive pourrait toujours être stocké sous forme de XML compressé. Mais maintenant, chaque page est stockée séparément. Ainsi, lors de l'ouverture d'un nouveau document, l'application pourrait simplement exécuter :

SELECT slideContent FROM slide WHERE pageNumber=1;

Cette requête renverra rapidement et efficacement le contenu de la première diapositive, qui pourrait alors être rapidement analysé et affiché à l'utilisateur. Une seule page doit être lue et analysée pour rendre le premier écran, ce qui signifie que le premier écran apparaît beaucoup plus rapidement et qu'il n'y a plus besoin d'une barre de progression ennuyeuse.

Si l'application voulait garder tout le contenu en mémoire, elle pourrait continuer à lire et à analyser les autres pages en utilisant un thread d'arrière-plan après avoir dessiné la première page. Ou, puisque la lecture de SQLite est si efficace, l'application pourrait plutôt choisir de réduire son empreinte mémoire et ne garder qu'une seule diapositive en mémoire à la fois. Ou peut-être qu'elle garde la diapositive actuelle et la suivante en mémoire, pour faciliter les transitions rapides vers la diapositive suivante.

Remarquez que la division du contenu en plus petits morceaux à l'aide d'une table SQLite donne de la flexibilité à l'implémentation. L'application peut choisir de lire tout le contenu en mémoire au démarrage. Ou elle peut lire seulement quelques pages en mémoire et garder le reste sur le disque. Ou encore, elle peut lire une seule page en mémoire à la fois. Et différentes versions de l'application peuvent faire des choix différents sans avoir à modifier le format du fichier. De telles options ne sont pas disponibles lorsque tout le contenu est dans un seul gros fichier XML dans une archive ZIP.

Le fractionnement du contenu en petits morceaux permet également d'accélérer les opérations File/Save. Au lieu de devoir réécrire le contenu de toutes les pages lors d'un File/Save, l'application ne doit réécrire que les pages qui ont réellement changé.

Un inconvénient mineur de la division du contenu en plus petits morceaux est que la compression ne fonctionne pas aussi bien sur les textes courts et donc la taille du document pourrait augmenter. Mais comme la majeure partie de l'espace du document est utilisée pour stocker les images, une petite réduction de l'efficacité de la compression du contenu textuel sera à peine perceptible, et c'est un petit prix à payer pour une expérience utilisateur améliorée.

Troisième amélioration : Le versionnement

Une fois que l'on est à l'aise avec le concept de stockage de chaque diapositive séparément, il n'y a qu'un petit pas à faire pour prendre en charge le versionnement de la présentation. Considérons le schéma suivant :

CREATETABLE slide(
  slideId INTEGERPRIMARYKEY,
  derivedFrom INTEGERREFERENCES slide,
  content TEXT-- XML or JSON or whatever);CREATETABLE version(
  versionId INTEGERPRIMARYKEY,
  priorVersion INTEGERREFERENCES version,
  checkinTime DATETIME,-- When this version was savedcommentTEXT,-- Description of this version
  manifest TEXT-- List of integer slideIds);

Dans ce schéma, au lieu que chaque diapositive ait un numéro de page qui détermine son ordre dans la présentation, chaque diapositive a un identifiant entier unique qui n'est pas lié à l'endroit où elle se trouve dans la séquence. L'ordre des diapositives dans la présentation est déterminé par une liste de slideIds, stockée sous forme de chaîne de texte dans la colonne MANIFEST de la table VERSION. Comme plusieurs entrées sont autorisées dans la table VERSION, cela signifie que plusieurs présentations peuvent être stockées dans le même document.

Au démarrage, l'application décide d'abord quelle version elle veut afficher. Puisque le versionId augmentera naturellement dans le temps et que l'on voudrait normalement voir la dernière version, une requête appropriée pourrait être :

SELECT manifest, versionId FROM version ORDERBY versionId DESCLIMIT1;

Ou peut-être que l'application préférerait utiliser le checkinTime le plus récent :

SELECT manifest, versionId,max(checkinTime)FROM version;

En utilisant une seule requête telle que celle ci-dessus, l'application obtient une liste des slideIds de toutes les diapositives de la présentation. L'application recherche ensuite le contenu de la première diapositive, puis analyse et affiche ce contenu, comme précédemment.

(A propos : Oui, la deuxième requête ci-dessus qui utilise "max(checkinTime)" fonctionne vraiment et renvoie une réponse bien définie en SQLite. Une telle requête renvoie soit une réponse indéfinie, soit génère une erreur dans de nombreux autres moteurs de base de données SQL, mais en SQLite, elle fait ce à quoi vous vous attendez : elle renvoie le manifeste et la versionId de l'entrée qui a le checkinTime maximum).

Lorsque l'utilisateur fait un "Fichier/Enregistrer", au lieu d'écraser les diapositives modifiées, l'application peut maintenant faire de nouvelles entrées dans la table SLIDE pour seulement les diapositives qui ont été ajoutées ou modifiées. Puis elle crée une nouvelle entrée dans la table VERSION contenant le manifeste révisé.

La table VERSION présentée ci-dessus comporte des colonnes pour enregistrer un commentaire d'enregistrement (vraisemblablement fourni par l'utilisateur) et l'heure et la date auxquelles l'action File/Save s'est produite. Elle enregistre également la version parent afin d'enregistrer l'historique des modifications. Le manifeste pourrait peut-être être stocké sous la forme d'un delta par rapport à la version parentale, bien qu'en général le manifeste soit suffisamment petit pour que le stockage d'un delta pose plus de problèmes qu'il n'en vaut la peine. La table SLIDE contient également une colonne derivedFrom qui pourrait être utilisée pour l'encodage des deltas s'il est déterminé que l'enregistrement du contenu de la diapositive comme un delta de sa version précédente est une optimisation intéressante.

Ainsi, avec ce simple changement, le fichier ODP stocke maintenant non seulement la modification la plus récente de la présentation, mais aussi un historique de toutes les modifications historiques. L'utilisateur voudra normalement voir seulement l'édition la plus récente de la présentation, mais s'il le souhaite, il peut maintenant remonter dans le temps pour voir les versions historiques de la même présentation.

Ou encore, plusieurs présentations pourraient être stockées dans le même document.

Avec un tel schéma, l'application n'aurait plus besoin de faire des sauvegardes périodiques des modifications non sauvegardées dans un fichier séparé pour éviter la perte de travail en cas de crash. Au lieu de cela, une version spéciale "en attente" pourrait être allouée et les changements non sauvegardés pourraient être écrits dans la version en attente. Étant donné que seules les modifications doivent être écrites, et non le document entier, l'enregistrement des modifications en attente n'implique que l'écriture de quelques kilo-octets de contenu, et non de plusieurs méga-octets, et prendrait des millisecondes au lieu de secondes, et pourrait donc être effectué fréquemment et silencieusement en arrière-plan. Ainsi, lorsqu'une panne survient et que l'utilisateur redémarre, tout (ou presque) son travail est conservé. Si l'utilisateur décide de jeter les modifications non sauvegardées, il revient simplement à la version précédente.

Il y a des détails à remplir ici. Peut-être peut-on prévoir un écran qui affiche un historique des modifications (peut-être avec un graphique) permettant à l'utilisateur de sélectionner la version qu'il veut voir ou modifier. Peut-être qu'une facilité peut être fournie pour fusionner les bifurcations qui pourraient se produire dans l'historique des versions. Et peut-être l'application devrait-elle fournir un moyen de purger les versions anciennes et indésirables. Le point clé est que l'utilisation d'une base de données SQLite pour stocker le contenu, plutôt qu'une archive ZIP, rend toutes ces fonctionnalités beaucoup, beaucoup plus faciles à mettre en œuvre, ce qui augmente la possibilité qu'elles soient finalement mises en œuvre.

Et ainsi de suite...

Dans les sections précédentes, nous avons vu comment le passage d'un magasin clé/valeur implémenté comme une archive ZIP à une simple base de données SQLite avec seulement trois tables peut ajouter des capacités importantes à un format de fichier d'application. Nous pouvons continuer à améliorer le schéma en ajoutant de nouvelles tables, des index pour améliorer les performances, des déclencheurs et des vues pour faciliter la programmation, ainsi que des contraintes pour assurer la cohérence du contenu, même en cas d'erreurs de programmation. D'autres idées d'amélioration comprennent :

  • Stocker une pile d'annulation/rétablissement automatisée dans une table de base de données afin que l'annulation puisse revenir sur des sessions d'édition antérieures.
  • Ajouter des capacités de recherche plein texte dans le diaporama, ou dans plusieurs diaporamas.
  • Décomposer le fichier "settings.xml" en une table SQL qui est plus facilement visualisée et éditée par des applications séparées.
  • Décomposez les "notes du présentateur" de chaque diapositive dans une table séparée, pour un accès plus facile à partir d'applications et/ou de scripts tiers.
  • Améliorez le concept de présentation au-delà de la simple séquence linéaire de diapositives pour permettre des chemins de traverse et des excursions en fonction de la réaction de l'auditoire.

Une base de données SQLite a beaucoup de capacités, que cet essai n'a fait qu'effleurer. Mais nous espérons que ce rapide aperçu a convaincu certains lecteurs que l'utilisation d'une base de données SQL comme format de fichier d'application vaut la peine d'un second regard.

Certains lecteurs pourraient résister à l'utilisation de SQLite comme format de fichier d'application en raison d'une exposition antérieure aux bases de données SQL d'entreprise et aux avertissements et limitations de ces autres systèmes. Par exemple, de nombreux moteurs de bases de données d'entreprise déconseillent de stocker de grandes chaînes de caractères ou des BLOB dans la base de données et suggèrent plutôt que les grandes chaînes de caractères et les BLOB soient stockés dans des fichiers séparés et que le nom du fichier soit stocké dans la base de données. Mais SQLite n'est pas comme ça. Toute colonne d'une base de données SQLite peut contenir une chaîne ou un BLOB d'une taille maximale d'environ un gigaoctet. Et pour les chaînes et les BLOB de 100 kilo-octets ou moins, les performances d'E/S sont meilleures que l'utilisation de fichiers séparés.

Certains lecteurs pourraient être réticents à considérer SQLite comme un format de fichier d'application parce qu'ils ont été inculqués avec l'idée que tous les schémas de base de données SQL doivent être factorisés en troisième forme normale et ne stocker que de petits types de données primitives comme les chaînes et les entiers. Il est certain que la théorie relationnelle est importante et que les concepteurs doivent s'efforcer de la comprendre. Mais, comme nous l'avons démontré ci-dessus, il est souvent tout à fait acceptable de stocker des informations complexes sous forme de XML ou de JSON dans les champs de texte d'une base de données. Faites ce qui fonctionne, pas ce que votre professeur de base de données a dit que vous deviez faire.

Revue des avantages de l'utilisation de SQLite

En résumé, l'affirmation de cet essai est que l'utilisation de SQLite comme conteneur pour un format de fichier d'application comme OpenDocument et le stockage de beaucoup de petits objets dans ce conteneur fonctionne beaucoup mieux que l'utilisation d'une archive ZIP contenant quelques objets plus grands. A savoir :

  1. Un fichier de base de données SQLite est approximativement de la même taille, et dans certains cas plus petit, qu'une archive ZIP contenant les mêmes informations.

  2. Les capacités de mise à jour atomique de SQLite permettent aux petites modifications incrémentielles d'être écrites en toute sécurité dans le document. Cela réduit les entrées/sorties totales du disque et améliore les performances de File/Save, ce qui améliore l'expérience de l'utilisateur.

  3. Le temps de démarrage est réduit en permettant à l'application de lire uniquement le contenu affiché pour l'écran initial. Cela élimine en grande partie la nécessité d'afficher une barre de progression lors de l'ouverture d'un nouveau document. Le document s'affiche immédiatement, ce qui améliore encore l'expérience utilisateur.

  4. L'empreinte mémoire de l'application peut être considérablement réduite en ne chargeant que le contenu pertinent pour l'affichage actuel et en conservant la majeure partie du contenu sur le disque. La capacité d'interrogation rapide de SQLite en fait une alternative viable au fait de garder tout le contenu en mémoire à tout moment. Et lorsque les applications utilisent moins de mémoire, cela rend l'ensemble de l'ordinateur plus réactif, ce qui améliore encore l'expérience utilisateur.

  5. Le schéma d'une base de données SQL est capable de représenter les informations de manière plus directe et succincte qu'une base de données clé/valeur telle qu'une archive ZIP. Cela rend le contenu du document plus accessible aux applications et aux scripts tiers et facilite les fonctionnalités avancées telles que le versionnement intégré du document et la sauvegarde incrémentielle du travail en cours pour la récupération après un crash.

Ce ne sont que quelques-uns des avantages de l'utilisation de SQLite comme format de fichier d'application - les avantages qui semblent les plus susceptibles d'améliorer l'expérience utilisateur pour des applications comme OpenOffice. D'autres applications pourraient bénéficier de SQLite de différentes manières. Consultez le document sur le format de fichier d'application pour des idées supplémentaires.

Enfin, répétons que cet essai est une expérience de pensée. Le format OpenDocument est bien établi et déjà bien conçu. Personne ne croit vraiment qu'OpenDocument devrait être modifié pour utiliser SQLite comme conteneur au lieu de ZIP. Cet article n'est pas non plus une critique d'OpenDocument pour ne pas avoir choisi SQLite comme conteneur puisque OpenDocument est antérieur à SQLite. Le but de cet article est plutôt d'utiliser OpenDocument comme un exemple concret de la façon dont SQLite peut être utilisé pour construire de meilleurs formats de fichiers d'application pour les projets futurs.