Bonjour,
Ce message s'adresse en particulier aux développeurs des solutions web service présentés au MoodleMoot mais intéressera certainement d'autres...
Je suis en train de regarder les web services pour Moodle au cas où j'en aurais besoin dans un prochain projet.
Que me conseillez-vous ? Dois je prendre les sources sur votre serveur ou sur le cvs Moodle ? Il y a un autre projet dans le cvs moodle intitulé dfws. Est-ce un concurent à votre développement ?
Que dois-je prendre ?
Il manque aussi, me semble-t-il, des fonctions. Comme par exemple les ajouts de personnes dans des groupes, etc... Y a-t-il des délais prévus pour que ces fonctions soient écrites ? Faut-il envisager de le faire moi même ?
Merci de vos réponses et à bientôt
Bonjour,
En voila une question qu'elle est bonne et à laquelle je suis bien embarrassé pour répondre...
Tout d'abord le code dans le CVS à cvs://cvs.moodle.org/contrib/patches/ws/wspp/ est exactement le même que celui sur http://cipcnet.insa-lyon.fr/Members/ppollet/public/moodlews/
Il y a simplement beaucoup plus de docs sur cipcnet, aussi que sur le site du MoodleMoot 2008 http://moodlemoot2008.vet-nantes.fr/moodle/course/view.php?id=56
Comme je ne cesse de le répéter dans les forums Moodle http://moodle.org/mod/forum/discuss.php?d=100065
mon implementation représentait un besoin à une époque (printemps 2007) ou il n'y avait rien dans Moodle en SOAP
et que le XML-RPC était soit pas fini (version de Glasgow), soit mal documenté (version officielle MNET)
Le projet dfws est la version officielle d'un API Web services sur lequel reposeront des clients comme
le mien ou celui de F. Hoestegel qui seront réécrits en virant nos couches basses. Il est même très probable que MNET sera réécrit pour s'appuyer sur cet API. Le problème est que
le développement de dfws est très lent, pas documenté et n'adresse toujours pas la question
primordiale de l'authentification et des droits/rôles associés ... Il était annoncé finalisé pour la fin de l'été .
Pour l'instant leur API, très élégante, est bien plus facile à maintenir que la mienne
puisqu'ils génèrent le WSDL "à la volée" à partir de fonctions déclarées dans le dossier apis ...
alors que Fred et moi le faisons "en dur" . Par contre ils ne s'intéressent toujours pas à la génération automatique
de clients ( voir mon wsdl2php ou les wsdl2java, wsdl2py ... bien connus des développeurs SOAP ) .
Leurs fonctions appellent les fonctions "réelles" dans lib/*.php ou mod/*/lib.php qui vérifient (normalement)
que l'utilisateur "courant" ($USER) peut le faire ... mais la remontée d'erreur est très sommaire ( false
en cas d'echec, mais on ne sait pas pourquoi ... et true sinon ...
Le problème est que la notion de login/logout n'est pas gérée. On ne sait toujours pas comment
ils vont le faire. On dirait bien qu'ils vont le mettre en session ... mais ce n'est pas clair.
Dans mon cas j'ai une technique ou l'appel à login renvoie une clé que l'on doit repasser à chaque appel,
d'ou deux paramètres supplémentaires à chaque fois ... j'avais proposé cette stratégie lors de la définition
de cette API ( voir http://docs.moodle.org/en/Development_talk:Web_services , onglets history ou discussion)
mais elle n'a pas été retenue.
Je suis à ce jour complètement bloqué. Je ne veux pas passer du temps à refaire ou à compléter mon client tant que
je ne suis pas sur de ce point qui est crucial . Sans parler du problème de la méthode d'authentification.
Tout ira bien en "manuel" ou "ldap" mais bien sur pas en CAS ni Shiboleth ... en effet un appel Web Services
ne peut pas être redirigé de force vers un serveur https CAS qui va renvoyer de l'HTML alors que le client attend de l'XML.
Le seul engagement que je peux prendre, si Dieu me prête vie, est que mes 50 points d'entrée actuels basés sur
des "get_" seront pérennes puisque des clients existent déjà en production ( Moodle eSup en java et Moodle Zope en python ).
Au pire leurs noms resteront en plus des versions respectant la nomenclature "officielle".
Mais je ne peux à ce jour donner aucune date . Le groupe espagnol qui développe dfws est assez peu collaboratif
et ne répond jamais à mes demandes sur ces points . Ils ont récemment changé la nomenclature des fonctions
(début novembre 2008) ... Je crois avoir compris que l'annonce de mon client SOAP a créé
une gène au Moodle HQ puisqu'ils avaient annoncé bien trop tôt qu'ils le feraient, mais que rien n'était prêt ...
seul le xml-rpc entre des Moodles parait fonctionnel avec MNET, mais j'avoue n'avoir rien compris à leur code ...
seule façon à ce jour puisqu'il n'y a rien que de sombres exemples "give me a beer" dans moodledocs.
En conclusion je crois, et j'en suis desolé, qu'il est urgent d'attendre. Ce qui explique que Frédéric et moi avont gelé
notre projet de fusion de nos deux clients comme annoncé au Moodle Moot 2008 alors qu'ils étaient complémentaires
et aurait permis d'avoir plus de 100 points d'entrée, et que je n'ai pas répondu à l'annonce
de l'ajout par K. Devellis des fonctions qui te manquent gérant les notes et les enrôlements aux groupes
http://moodle.org/mod/forum/discuss.php?d=102511, bien que je les ai ajoutés mais pas commitées dans le cvs .
Voila.
NB: je serais très intéressé par les commentaires ici d'autres utilisateurs du Web Service et de leur attente dans les mois à venir. Forker ou ne pas forker, that is the question
En voila une question qu'elle est bonne et à laquelle je suis bien embarrassé pour répondre...
Tout d'abord le code dans le CVS à cvs://cvs.moodle.org/contrib/patches/ws/wspp/ est exactement le même que celui sur http://cipcnet.insa-lyon.fr/Members/ppollet/public/moodlews/
Il y a simplement beaucoup plus de docs sur cipcnet, aussi que sur le site du MoodleMoot 2008 http://moodlemoot2008.vet-nantes.fr/moodle/course/view.php?id=56
Comme je ne cesse de le répéter dans les forums Moodle http://moodle.org/mod/forum/discuss.php?d=100065
mon implementation représentait un besoin à une époque (printemps 2007) ou il n'y avait rien dans Moodle en SOAP
et que le XML-RPC était soit pas fini (version de Glasgow), soit mal documenté (version officielle MNET)
Le projet dfws est la version officielle d'un API Web services sur lequel reposeront des clients comme
le mien ou celui de F. Hoestegel qui seront réécrits en virant nos couches basses. Il est même très probable que MNET sera réécrit pour s'appuyer sur cet API. Le problème est que
le développement de dfws est très lent, pas documenté et n'adresse toujours pas la question
primordiale de l'authentification et des droits/rôles associés ... Il était annoncé finalisé pour la fin de l'été .
Pour l'instant leur API, très élégante, est bien plus facile à maintenir que la mienne
puisqu'ils génèrent le WSDL "à la volée" à partir de fonctions déclarées dans le dossier apis ...
alors que Fred et moi le faisons "en dur" . Par contre ils ne s'intéressent toujours pas à la génération automatique
de clients ( voir mon wsdl2php ou les wsdl2java, wsdl2py ... bien connus des développeurs SOAP ) .
Leurs fonctions appellent les fonctions "réelles" dans lib/*.php ou mod/*/lib.php qui vérifient (normalement)
que l'utilisateur "courant" ($USER) peut le faire ... mais la remontée d'erreur est très sommaire ( false
en cas d'echec, mais on ne sait pas pourquoi ... et true sinon ...
Le problème est que la notion de login/logout n'est pas gérée. On ne sait toujours pas comment
ils vont le faire. On dirait bien qu'ils vont le mettre en session ... mais ce n'est pas clair.
Dans mon cas j'ai une technique ou l'appel à login renvoie une clé que l'on doit repasser à chaque appel,
d'ou deux paramètres supplémentaires à chaque fois ... j'avais proposé cette stratégie lors de la définition
de cette API ( voir http://docs.moodle.org/en/Development_talk:Web_services , onglets history ou discussion)
mais elle n'a pas été retenue.
Je suis à ce jour complètement bloqué. Je ne veux pas passer du temps à refaire ou à compléter mon client tant que
je ne suis pas sur de ce point qui est crucial . Sans parler du problème de la méthode d'authentification.
Tout ira bien en "manuel" ou "ldap" mais bien sur pas en CAS ni Shiboleth ... en effet un appel Web Services
ne peut pas être redirigé de force vers un serveur https CAS qui va renvoyer de l'HTML alors que le client attend de l'XML.
Le seul engagement que je peux prendre, si Dieu me prête vie, est que mes 50 points d'entrée actuels basés sur
des "get_" seront pérennes puisque des clients existent déjà en production ( Moodle eSup en java et Moodle Zope en python ).
Au pire leurs noms resteront en plus des versions respectant la nomenclature "officielle".
Mais je ne peux à ce jour donner aucune date . Le groupe espagnol qui développe dfws est assez peu collaboratif
et ne répond jamais à mes demandes sur ces points . Ils ont récemment changé la nomenclature des fonctions
(début novembre 2008) ... Je crois avoir compris que l'annonce de mon client SOAP a créé
une gène au Moodle HQ puisqu'ils avaient annoncé bien trop tôt qu'ils le feraient, mais que rien n'était prêt ...
seul le xml-rpc entre des Moodles parait fonctionnel avec MNET, mais j'avoue n'avoir rien compris à leur code ...
seule façon à ce jour puisqu'il n'y a rien que de sombres exemples "give me a beer" dans moodledocs.
En conclusion je crois, et j'en suis desolé, qu'il est urgent d'attendre. Ce qui explique que Frédéric et moi avont gelé
notre projet de fusion de nos deux clients comme annoncé au Moodle Moot 2008 alors qu'ils étaient complémentaires
et aurait permis d'avoir plus de 100 points d'entrée, et que je n'ai pas répondu à l'annonce
de l'ajout par K. Devellis des fonctions qui te manquent gérant les notes et les enrôlements aux groupes
http://moodle.org/mod/forum/discuss.php?d=102511, bien que je les ai ajoutés mais pas commitées dans le cvs .
Voila.
NB: je serais très intéressé par les commentaires ici d'autres utilisateurs du Web Service et de leur attente dans les mois à venir. Forker ou ne pas forker, that is the question
Je pense qu'il faut committer !! Même si plus tard, les choses évoluront !
En plus si vous avez plus de 100 points d'entrée cela donne du poids à votre développement et fera peut etre bouger les choses.
Dans mon cas, j'ai eu besoin de Login / Logout / Get_My_Courses !! pour dire !
Et je suis super content d'avoir maintenant un lien SOAP entre une application iPhone et un serveur Moodle.
A+
En plus si vous avez plus de 100 points d'entrée cela donne du poids à votre développement et fera peut etre bouger les choses.
Dans mon cas, j'ai eu besoin de Login / Logout / Get_My_Courses !! pour dire !
Et je suis super content d'avoir maintenant un lien SOAP entre une application iPhone et un serveur Moodle.
A+
Florent > Je pense qu'il faut committer !
Je dirais plutôt "valider". Mais la traduction de "to commit" ne fait pas l'unanimité, voir ces échanges.
Joseph
Dans mon cas > Mettre à disposition de tous, des morceaux de codes qui peuvent être intéréssant pour l'ensemble de la communauté !!!
Bonjour,
J'ai installé MoodleWS et épucher les fonctions disponible. Il m'est ainsi facile d'ajouter un cours.
Malheureusement, le cours que je dois ajouter est au format scorm et je n'ai trouvé aucune fonction pour ajouter directement le fichier zip via le web service. Y aurait-il un moyen de faire cela où dois-je intégrer moi-me cette fonctionnalité? Si tel est le cas, par quoi dois-je commencer, sachant que le plugin est assez conséquent et qu'il ne me reste que peu de temps pour faire tout cela.
Merci d'avance,
J'ai installé MoodleWS et épucher les fonctions disponible. Il m'est ainsi facile d'ajouter un cours.
Malheureusement, le cours que je dois ajouter est au format scorm et je n'ai trouvé aucune fonction pour ajouter directement le fichier zip via le web service. Y aurait-il un moyen de faire cela où dois-je intégrer moi-me cette fonctionnalité? Si tel est le cas, par quoi dois-je commencer, sachant que le plugin est assez conséquent et qu'il ne me reste que peu de temps pour faire tout cela.
Merci d'avance,