Le Mon, 2 May 2016 16:14:49 +0200, Charlène Servantie <servantie.c@gmail.com> a écrit :
Suite aux discussions de vendredi dernier, voici une deuxième version du schéma, avec pour changements principaux : la prise en compte d'un id pour les temps, et l'ajout d'une date de début et d'une date de fin pour définir l'intervalle de mise à jour, la date de fin étant optionnelle (si elle n'est pas présente, la mise à jour prend comme fin de période la date courante). Le terme de path a été changé en id pour pouvoir coller à différents modèles (dans le cas de jtimer il s'agit du path de la tâche, pour wid ça pourra être le tag).{
"description": "schema for the update of the times of a project/task", "$schema": "http://json-schema.org/draft-04/schema#",
"definitions": { "task": { "type":"object", "properties": { "id": {"type": "string"}, "startDate" : {"type": "string"}, "endDate" : {"type": "string"}, "totalTime": {"type":"integer"}, "periods": { "type":"array", "items" : { "type" : "object", "properties": { "id": {"type":"string"}, "startDate":{"type" : "string"}, "duration": {"type":"integer"} } }, "minItems" : 1 }, "name": {"type": "string"}, "annotation": {"type": "string"}, "subtasks": { "type": "array", "items": {"$ref":"#/definitions/task"} } }, "required":["id", "startDate", "totalTime", "periods"] } }, "type":"object", "properties": { "task": {"$ref":"#/definitions/task"} } }
avec un exemple :
{ "id":"path/le/chien", "startDate":"2002/02/02T00:00:00.000Z", "totalTime":300, "periods": [ {"id": "anAmazingID", "startDate":"2016/04/03T00:00:00.000Z", "duration":175}, {"id": "anOtheriD", "startDate": "2002/02/02T00:00:00.000Z", "duration": 78}, {"id": "IDitAgain", "startDate": "2006/10/20T00:00:00.000Z", "duration":58} ], "name":"6882", "annotation":"bla", "subtasks": [ ]
}
Salut, Le format a été de nouveau "discuté" cette après-midi. Il en ressort que : - il est nécessaire de pouvoir identifier le serveur de synchronisation d'une tache (au dela du simple envoi de temps, cela peut permettre de stopper/configurer les appels effectués sur ce serveur (en cas de looooongue maintenance serveur par exemple) - la hiérachie, on s'en fout, parce que "si le serveur doit faire le boulot de tri, pourquoi le client ne le fait pas lui même ?" (ou à peu près cette raison) - une "tâche" (si l'on peut encore utiliser ce terme) doit être définie par : - un identifiant (cela peut etre l'url de synchronisation) - un objet metadata (avec la date de début de synchronisation et son éventuelle fin) - les datas (~periods), qui sont une liste de datas, composées d'un id, d'un début (date UTC et charge au serveur de savoir si le fuseau horaire de la personne est de l'autre coté de la planète ?) et d'une durée, ainsi que d'un commentaire (ie: annotation) Ce qui ne sert à rien parce qu'on ne veut que du temps à synchroniser : - nom de la "tache" - enfants (les temps sont à reporter sur le plus proche parent avec une url de synchro sur le serveur demandé) Il faut aussi songer à la partie récupération des données depuis le serveur (ie: url de synchro). À l'appel d'une URL en GET, le serveur doit être capable de donner : - une arborescence (sic) du projet avec les différents noeuds sur lesquels envoyer des temps. Depuis cette information, il conviendra alors au client de faire le mapping entre l'arborescence fournie et sa façon de pointer ses temps. Allez, courage... -- Yannick Martel Code Lutin <http://www.codelutin.com/> +33 2 40 50 29 28