Version 7 — Octobre 2013 — severo
Pour réfléchir autour de l’idée d’une API et d’un système client/serveur pour la conversion de fichiers (documents, images, son, vidéos).
On veut pouvoir permettre à un site hébergé sur un serveur ne proposant pas les outils système de conversion, de pouvoir déléguer ce travail à un autre site.
Un autre objectif est de mieux modulariser les plugins existants de conversion (doc2img, spipmotion, ocr, oficina, fulltext), en séparant ce qui relève de la conversion, de l’indexation, du stockage et de la publication (affichage et téléchargement) des documents. L’API se chargera uniquement du module de conversion.
Je liste ici toutes les actions de conversion qu’effectuent les plugins actuels + celles qu’on peut imaginer.
Fichier en entrée | Action | Résultat | Actuellement |
---|---|---|---|
Documents doc, ou odt, rtf... | |||
doc | convertir en odt | odt | |
doc | convertir en PDF | office2spip | |
doc | générer un vignette (image de la première page) | png | |
doc | générer une image par page | plusieurs png | |
doc | extraire le texte brut | texte | |
doc | convertir en HTML (avec option pour intégrer les images en base64) | html | oficina |
Documents PDF, ou tiff multipage, ps, epub ? | |||
générer un vignette (image de la première page) | png | doc2img | |
générer une image par page | plusieurs png | doc2img | |
extraire le texte brut (avec option OCR si aucun texte n’est inclus directement) | texte | fulltext, ocr | |
convertir en HTML (avec option pour intégrer les images en base64) | html | ||
convertir en doc (éventuellement) | doc | ||
Images | |||
png | convertir en un autre format | jpg | doc2img |
png | extraire le texte brut par OCR | texte | ocr |
Sons | |||
mp3 | encoder en un autre format | ogg | spipmotion |
mp3 | extraire le texte correspondant (reconnaissance vocale, on peut rêver) | texte | |
Vidéos | |||
avi | encoder en un autre format | ogv | spipmotion |
avi | extraire le texte correspondant (sous-titres automatiques, on peut rêver) | texte |
Le principe est le suivant : le client envoie un fichier au serveur en lui indiquant quel type de conversion il souhaite, le serveur le convertit puis met à disposition du client le résultat de la conversion.
Durant le temps de la conversion, l’URL retourne un statut HTTP qui indique que la conversion n’est pas fini. Lorsque le résultat est prêt, l’URL retourne le résultat. Le client doit demander donc accéder régulièrement au serveur à l’URL pour savoir si la conversion est terminée ou non.
Détails du serveur
Le serveur doit savoir :
Détails du client
Le client doit savoir :
API - Envoi du fichier et demande de conversion
Première requête
La première requête du client vers le serveur peut contenir :
-* URL vers le fichier à télécharger , ou dans le cas d’une requête POST ( Content-Type multipart/form-data ) le fichier en lui même ,
-* liste de paramètres pour la conversion
Plus de détails
Réponses possibles du serveur Un requête vers cette URL rendra la réponse suivante :
API - Avancement de la conversion
Une fois la conversion en cours, le client peut effectuer une requête vers l’URL spécifique. Le serveur peut répondre :
La réponse 200 peut être sous une des trois formes suivantes (voir http://zone.spip.org/trac/spip-zone/browser/_plugins_/oficina/action/oficina_api_v1.php#L24 ) Une fois le fichier converti , le serveur peut proposer le résultat sous les formes suivantes :
API - Commandes d’administration Plugins en relation
Le plugin oficina propose une autre commande (http://zone.spip.org/trac/spip-zone/browser/_plugins_/oficina/action/oficina_api_v1.php#L67) pour permettre à un administrateur de créer une clé d’accès pour un tiers.
Si le client est authentifié comme un administrateur, et qu’il envoie le paramètre « for=toto », le serveur répondra :
API - autres commandes ?
Le serveur authentifie le client, et donne lui donne accès à tout ou partie des actions. On peut éventuellement imaginer que le serveur publie la liste des actions dont il est capable (méta-données décrivant le contenu du service et les paramètres acceptés). Voir par exemple la commande GetCapabilities du service Web WMS : https://fr.wikipedia.org/wiki/Web_Map_Service.
Exemple du plugin oficina
Les paramètres envoyés au serveur peuvent être (voir plugin oficina) :
Ce que l’API ne fera pas
Publier le fichier converti sur le serveur. Le résultat ne sera accessible que par le client. Éventuellement, s’il existe un autre plugin de publication à distance (genre CDN), on pourra les coupler pour que la conversion d’une vidéo, par exemple, retourne en résultat un code HTML d’embed, ou une URL oembed, la visualisation de la vidéo convertie se faisant pour les visiteurs sur le serveur « CDN ».
Il existe déjà plusieurs plugins de conversion, d’analyse, d’indexation, ou de gestion des travaux. Les plugins suivants existants peuvent être éventuellement modifiés pour utiliser l’API d’une manière ou d’une autre reliés : doc2img, spipmotion, facd, ocr, oficina, mediaspip_core, fulltext
Dans le cas où le client et le serveur sont installés sur est aussi installé dans le même site, il faut prévoir un mécanisme pour éviter les requêtes HTTP le client peut court-circuiter l’API et accéder directement aux commandes système .
Est-ce qu’un Il faut se poser la question de savoir si un seul plugin peut fournir l’API pour toutes les actions de conversion, ou faut-il s’il faut une API différente pour chaque type de fichier, en raison des paramètres différents (résolution pour les images, taux compression pour le son et les vidéos , ... échantillonage ? pour le son, ...).
Est-ce qu’utiliser une boucle DATA a un sens pour récupérer les données sur le serveur ? Avec un critère clé ou url_specifique ?