Valery Fremaux

Jérome, le correcteur orthographique sous Moodle 2 nécessite une configuration dans le code du tinyMCE qui n'a pas été reportée en standard. Nous avons backporté l'éditeur TinyMCE qui en effet est bien plus stable (l'un des quelques avantages positifs de Moodle 2.0).

Concernant la discussion générale, et du fait de notre relation courante avec d'autres Moodle Partners (Ennovation, Catalyst, Act2Win, Andrea Bicciolo, Wafa Adham Ltd. etc.), un constat décevant est en effet apparu qui pousse la plupart des Moodle Parners actifs à fonder des variantes "privées" basées sur une continuité de Moodle 1.9. (Cf Totora). Les arguments généralement constatés sont :

Positifs : 

• La mise en objet de l'accès à la base de données => plus simple pour pouvoir travailler avec plusieurs bases différentes dans certaines cas
• L'objectivation du thème (codage plus clair et poussant les devs à utiliser les API plus couramment).
• La généralisation de certaines structures pas abouties en 1.9 (Web services généralisés, fonctions XMLRPC supportées par la plupart des modèles de plugins).
• Un peu de nettoyage des mécansimes de langue qui étaient parfois bien tordus.

Au rang des (GROS) griefs :

• La nouvelle gestion des fichiers basées sur l'usages de Repositories externes (les répositories internes sont incompréhensibles), mais sans finaliser une ergonomie claire.
• La gestion interne des fichiers : on paye très cher la sécurisation et l'optimisation du stockage, il y avait plein d'autres solutions.
• La complexité des nouveaux mécanismes de base qui va rendre encore plus dure l'implémentation complète et correcte de plugins. Je ne suis pas sûr que cette montée vers l'élitisme soit involontaire, vu les réponses apportées par MD au MoodleMoot de Troyes.
• Le non aboutissement de manques de structure depuis longtemps signalés dans Moodle 1.9, qui gênent tous les intégrateurs, et qui ne sont toujours pas résolus.
• La nouvelle navigation : Peut être plus interessante dans les plates-formes universitaires, mais toutes nos expériences vont AU CONTRAIRE vers une demande systématique de la simplification de l'interface et non de sa concentration. Il faut savoir en effet qu'aujourd'hui le marché "professionnel" de l'intégration Moodle est à 80% axé sur la formation continue et non les formations scolaires ou universitaires.
• Des promesses intéressantes sur le papier, mais dont l'implémentation reste très incomplète (suivi des progresion) ou peu utilisables à grand échelle (activités conditionnelles).

En général, un éloignement encore plus grand des modèles de formation continue qui font vivre 70% des projets d'intégration aujourd'hui. Nous comptons bien d'ailleurs sur les premières écoles et universités pionnières pour débrouiller le bon du moins bon et influer de tout leurs messages et votes sur les HQ pour rectifier le tir... m'est avis qu'aujourd'hui, le backporting des solutios les plus intéressantes reste aujourd'hui la seule voie envisageable pour les prestations que nous faisons :

Personne n'est encore d'accord pour financer le surcoût d'une intégration Moodle 2.0 et ses conséquences en besoins de développement complémentaires.  

Pour toutes ces raisons, à Val'EISTI, nous ne considérons (on a tenté de jouer le jeu, réellement pourtant) aucun nouveau projet sous Moodle 2.0 (sauf le fusil sous le nez, ou alors un super budget dans le panier !). En tout cas, aujourd'hui à moins de commandes directes explicites, nous ne pouvons supporter une double maintenance des modules dont nous nous occupons, et je pense que de nombreux producteurs de modules sont dans le même cas. 

Cheers.

En attendant que je mette la main sur le doc, quelques infos importantes pour pas se lancer dans le vide :

Openmeetings tourne sur un serveur Red5, lui même une surcourche d'un serveur Tomcat (ou Jetty, mais en tous cas un moteur de servlet J2EE), donc easyphp ne pourra pas faire grand chose ici...

Il faut donc installer tout l'arsenal Java 6. Red5 vient avec un tomcat intégré donc pas la peine d'en installer un .

Openmeetings est une "Webapp" c'est à dire :

- un jeu de servlets écrits en Java qui reçoivent les différentes requêtes de contrôle, et d'autres pour traiter les flux (normalement traités en natifs par Red5, mais je nage encore dans la "Documentation 0" du projet Red5)

Un player Flash (avec plein de ressources annexes) pour être projeté dans une page HTML qui sert de container. Le plugins openmeetings de Moodle charge ce player dans une "frame". Ce player est spécialement conçupour dialoguer avec le jeu de servlets précédents.

Côté hébegement : il est EVIDENT qu'il faut un dédié pour passer, même plutôt un moyen qu'un petit : Les flux vidéo et audio continus traités en streaming temps réel sont TRES DEMANDEURS en ressources, et ce type d'usage est incomptable avec un autre usage du serveur (par exemple un site Web à forte fréquentation). 

Côté bande passante : il faut compter AU MOINS 350 ko / utilisateur connecté. Ce qui donne pour 300 personne simultanées un joli 100Mo de bande stable. C'est là ou les réunions en ligne commencent à sortir du bricolage. Et c'est ce qui explique aussi le coût qu'imposent les prestataires actuellement sur le marché. 100Mo de bande garanti pour la machine, on est sur des contrats de location "Pro".

Côté RAM je manque encore de données. On doit monter un nagios pour mesurer notre openmeetings en montée de charge.... pas encore d'infos pour savoir combien de RAM mange chaque utilisateur.

Il est évident que plus on a de coeurs sur la machine mieux c'est : ces services sont hautement parralélisables et distribuables sur plusieurs processeurs, à l'exception du goulet d'étranglement que pourrait représenter la carte réseau.

Voilà pour un premier brief sur la situaiton. Les loueurs de réunion (Centra, WebEx, Adobe connect, Classilio, etc. entretiennent évidemment une infrastructure réseau et hard lourde pour faire tourner et fournir le service. Openmeetings peut être une solution intermédiaire, mais pas magique. Elle rajoute des coûts de gestion système et n'ampute pasles coûts de location de la bande.

A plus.  

Pour répondre pratiquement : quel système as-tu ?

nous avons un guide d'install pour Debian dispo.... (faut que je demande à mon support sys).

Cheers

En effet, Joseph, cela ne sert à rien .... lorsque c'est implémenté à moitié.

Le seul intérêt de ces métadescriptions est lorsque cette complexité technique s'enterre complètement dans des outils utilisateur et devient transparente. Autrement, on prend le risque d'une techno-aversion des utilisateurs, bien légitime.

Il faut comprendre les métadonnées comme un "moyen" d'obtenir des améliorations fonctionnelles et non comme une fin en soi. Implémenter les métadonnées pour répondre à une doxa informaticienne ou techno-documentaire est inutile, contreproductif sur les usages et renforce le déphasage entre ce que la technologie a à proposer et les usages.

Il n'y a qu'à voir comment on a pu une seule minute proposer un outil comme Reload aux enseignants pour monter des paquetages SCORM !!

du grand n'importe quoi.

Amitiés.

Ce projet est en cours chez nous. Avec un développement prévu d'Avril à Juillet.

La saisie de métadonnées est conceptuellement simple à considérer, beaucoup plus compliquée à mettre en oeuvre "au bon niveau".

Fait de manière trop simpliste, elle est obligée de faire une sélection de ce qui sert  et de ce qui ne sert pas et personne n'a le même avis sur ce qui sert et sur ce qui  ne sert pas.

Si on suit les normes jusqu'au bout, le formulaire est brutalement complexe (formulaire multiniveau à listes ouvertes) et il faut intégrer tous les vocabulaires. Ce qui donne des formulaires d'une lourdeur rédhibitoire.

La solution que nous mettons en place prend en compte tout cela, en visant une implémentation complète des normes, mais avec des filtres pour extraire par choix ce qui sert et ne sert pas :

filre enseignant (auteur) : le minimum de champs pour pas fatiguer

filtre documentaliste : plus de champs, pour abonder et améliorer le référencement

filtre administrateur : pour choisir parmi l'exhaustivité complète, ce qui est implémenté dans le moodle.

Par contre, vu la position très centrale du module "mod/resource", nous ne pouvons appliquer ce projet à ce module, mais à un module "sharedresource" qui offre une librairie d'objets partagés entre tous les cours (superressources).

Reste le problème des vocabulaires que l'on aimerait pouvoir filtrer aussi, on va voir avec mon stagiaire si on peut trouver une astuce architecturale pour ça, car certaines listes adressent des items qui ne sont pas pertienents pour certains environnement. Par contre, impossible de "rajouter" des items car cela dénormaliserait les listes. Nous devons également faire attention à ce que des données importées avec des items ignorés localement puissent réactiver ces items dans les listes de choix de recherche etc.

Comme vous voyez le problème n'est pas simple, si on veut le traiter correctement.....