Question intéressante. La partie serveur permet d'avoir certaines fonctionnalités comme la synchronisation de la position de lecture, mais pas seulement. Elle joue aussi un rôle important pour la simple lecture des fichiers epub.
Un epub est un zip qui contient des fichiers HTML, avec les images, CSS, JS, etc. qui vont avec, plus des métadonnées. On pourrait envoyer simplement le fichier epub au navigateur, puis faire tous les traitements coté client. Blaine Cook a, par exemple, écrit rePublish sur ce principe. Mais, on atteint vite certaines limites avec les ebooks que l'on peut acheter en ligne.
Prenons une BD au format epub (epub3 en fixed layout pour être précis), on va avoir un fichier HTML par page, et chaque page va afficher une image avec une résolution assez élevée. Le fichier va donc faire quelques Mo, disons 10 Mo. Des bibliothèques JS pour dézipper, ça existe mais celles que j'ai vu sont loin d'être aussi performantes qu'un unzip coté serveur. Sur un PC puissant, attendre une dizaine de secondes que le fichier 10Mo soit dézippé reste acceptable mais sur une tablette, vous risquez d'avoir fini votre trajet en métro avant que ça n'ait fini ;-)
En fait, j'ai même vu pire : Safari a préféré se suicidé lorsque j'ai fait ce genre de tests sur un ipad (au passage, je n'ai pas su si c'était à cause de la mémoire ou du CPU, quelqu'un aurait une idée de comment faire la différence ?). Du coup, avoir une partie serveur permet de profiter de toute la puissance d'un vrai PC pour l'opération de dézippage plutôt que d'être limité par celle d'une tablette.
Autre cas : on peut aussi trouver en epub des romans. On a notamment travaillé sur des best-sellers. On pourrait donc s'attendre à ce que les éditeurs aient un budget correct et que ces ebooks soient parmi ceux de meilleure qualité. Hé bien, pas vraiment. Dans certains cas, le HTML a l'intérieur de ces livres est une bouillie infâme (quelques centaines d'erreurs au validateur du w3c par chapitre). Pour d'autres, ce sont les chemins vers les images qui ne sont pas (les images sont dans un répertoire écrit en minuscules alors que le src des img fait référence au répertoire en majuscules, voire oublie complètement le répertoire en question).
On est donc obligé de préparer les ebooks à l'avance et ce travail est bien plus facile à faire coté serveur que coté client (tout particulièrement pour les histoires d'encodage). Ces hacks se trouvent dans le fichier app/models/ebook/epub.rb pour ceux qui voudraient y jeter un coup d’œil.
Enfin, il y avait aussi des raisons pratiques pour gagner un peu de temps de développement. Par exemple, on pourrait croire qu'extraire la couverture d'un epub est simple, mais pas vraiment. Du coup, avoir des bibliothèques comme Peregrin aide pas mal. Mais, ça reste anecdotique : les principales raisons du choix d'avoir une partie serveur ont été les fonctionnalités que cela apporte et les contraintes techniques (performances principalement).
[^] # Re: EPUB = ZIP + XML + HTML
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Lisez en liberté avec TeaBook Open Reader !. Évalué à 8.
Question intéressante. La partie serveur permet d'avoir certaines fonctionnalités comme la synchronisation de la position de lecture, mais pas seulement. Elle joue aussi un rôle important pour la simple lecture des fichiers epub.
Un epub est un zip qui contient des fichiers HTML, avec les images, CSS, JS, etc. qui vont avec, plus des métadonnées. On pourrait envoyer simplement le fichier epub au navigateur, puis faire tous les traitements coté client. Blaine Cook a, par exemple, écrit rePublish sur ce principe. Mais, on atteint vite certaines limites avec les ebooks que l'on peut acheter en ligne.
Prenons une BD au format epub (epub3 en fixed layout pour être précis), on va avoir un fichier HTML par page, et chaque page va afficher une image avec une résolution assez élevée. Le fichier va donc faire quelques Mo, disons 10 Mo. Des bibliothèques JS pour dézipper, ça existe mais celles que j'ai vu sont loin d'être aussi performantes qu'un
unzipcoté serveur. Sur un PC puissant, attendre une dizaine de secondes que le fichier 10Mo soit dézippé reste acceptable mais sur une tablette, vous risquez d'avoir fini votre trajet en métro avant que ça n'ait fini ;-)En fait, j'ai même vu pire : Safari a préféré se suicidé lorsque j'ai fait ce genre de tests sur un ipad (au passage, je n'ai pas su si c'était à cause de la mémoire ou du CPU, quelqu'un aurait une idée de comment faire la différence ?). Du coup, avoir une partie serveur permet de profiter de toute la puissance d'un vrai PC pour l'opération de dézippage plutôt que d'être limité par celle d'une tablette.
Autre cas : on peut aussi trouver en epub des romans. On a notamment travaillé sur des best-sellers. On pourrait donc s'attendre à ce que les éditeurs aient un budget correct et que ces ebooks soient parmi ceux de meilleure qualité. Hé bien, pas vraiment. Dans certains cas, le HTML a l'intérieur de ces livres est une bouillie infâme (quelques centaines d'erreurs au validateur du w3c par chapitre). Pour d'autres, ce sont les chemins vers les images qui ne sont pas (les images sont dans un répertoire écrit en minuscules alors que le
srcdesimgfait référence au répertoire en majuscules, voire oublie complètement le répertoire en question).On est donc obligé de préparer les ebooks à l'avance et ce travail est bien plus facile à faire coté serveur que coté client (tout particulièrement pour les histoires d'encodage). Ces hacks se trouvent dans le fichier
app/models/ebook/epub.rbpour ceux qui voudraient y jeter un coup d’œil.Enfin, il y avait aussi des raisons pratiques pour gagner un peu de temps de développement. Par exemple, on pourrait croire qu'extraire la couverture d'un epub est simple, mais pas vraiment. Du coup, avoir des bibliothèques comme Peregrin aide pas mal. Mais, ça reste anecdotique : les principales raisons du choix d'avoir une partie serveur ont été les fonctionnalités que cela apporte et les contraintes techniques (performances principalement).