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