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": [ ] }
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
Le 04/05/2016 21:49, Yannick Martel a écrit :
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) Quelle différence par rapport au début de l'URL ? (c'est à dire nom du serveur + contexte web) Je ne comprend pas la pertinence d'une telle information. Un besoin non exprimé ?
- 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)
Oui, on s'en fout si l'outil qui émet (WID) n'a pas l'info... Si il a l'info (jTimer), aucune raison de ne pas l'envoyer. Donc oui, c'est une info optionnelle, mais non on s'en fout pas.
date UTC et charge au serveur de savoir si le fuseau horaire de la personne est de l'autre coté de la planète ?
Bah non, c'est ridicule. Pourquoi s'inventer des problèmes ?
Ce qui ne sert à rien parce qu'on ne veut que du temps à synchroniser : - nom de la "tache" Why not.
- enfants (les temps sont à reporter sur le plus proche parent avec une url de synchro sur le serveur demandé)
Faux. Encore une fois, on essaye de définir un format générique et non pas WID-compatible uniquement, merci de le respecter.
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.
Je suis complètement contre, c'est hors sujet (en tout cas en ce qui concerne le stage de Charlène).
Allez, courage...
Mais oui, ça va aller vu que c'est Yannick qui a le dernier mot \o/ Arnaud
participants (3)
-
Arnaud Thimel -
Charlène Servantie -
Yannick Martel