Valery Fremaux

Hi Koen,

The fact is that xxxtotext converters can only be invoked within the Moodle distribution directory. 

Installing antiword and xpdf as standalone packages will not comply with this rule. This was done for a future complete integration of thoses libraries in the /lib distribution, and in case some security settings of PHP and Apache would have restricted access to that executable elsewhere.

This is a restriction I may spit off, but we should have a global developper and architecture discussion before.

In the meanwhile, ensure executable are within <%%Moodleroot%%>. I confess I have no implementation running actually on Linux to evaluate deployement issues. This will come soon, I hope.

Rules are :

I take the value given for the path of the executables, and then the executable is found using the following construction :

            $text_converter_cmd = "{$CFG->dirroot}/{$CFG->block_search_pdf_to_text_cmd} $file -";

for PDF, and

            $text_converter_cmd = "{$CFG->dirroot}/{$CFG->block_search_word_to_text_cmd} $file";

for Word

Could this help you to setup the search engine. I will add some references to that point in Moodledocs.

SCORM :

Oui effectivement, RELOAD est un modèle du type d'application incompréhensible pour les enseignants, lourde pour les utilisateurs même expérimentés, et donc pratiquement totalement inutile sauf pour les quelques spécialistes techniques du SCORM.

Il faut donc trouver des automatisations de production des manifest qui soient quasiment "transparentes".

Quand ça a marché, c'est sur combien d'essais ? Il faut toujours se méfier de ce qui marche, car ça peut marcher sur quelques "cas qui vont bien".

sinon bravo.

SEARCH :

Le moteur (LUCENE, Zend) indexe complètement deux champ de texte (quand je dis indexe, c'est qu'il prend tous les mots, vire quelques mots non indexables puis calcule un rétroindex binaire avec toutes les positions de mots.

Ces champs sont 'title' et 'content'. C'est donc un moteur dit "fulltexte". C'est ensuite un choix que de ne mettre, dans le titre par exemple, que les mots-clefs.

En théorie, il serait possible d'ajouter n'importe quel champ supplémentaire au moteur. Par contre, si on le fait, ce sera une modification générale du moteur avec revue de tous les adapteurs. Rajouter un champ "keywords" permettrait en effet d'autoriser une recherche spécifique sur les mots-clefs.

A l'usage, et "ethnoinformatiquement", cela semble assez inutile en fait, car la recherche fulltext donne toujours des meilleurs résultats que les recherches basées sur les mots-clefs : En effet, le jeu de mots clef est pensé par l'auteur au moment où il produit son document. Le mots utilisés pour la recherche sont pensés par le chercheur, au moment et dans le contexte où il cherche. Le fulltext a de bien plus grandes chances de laisser le contexte du chercheur matcher avec le contenu.    

Some last new from the Tracker module being reengineered :

We had till some month/years yet the Tracker module that was not working as it was not terminated (student job). Code is growing fast and will provide a simple but well featured bugtracker for Moodle end-users to Admins.

• Bug reporting
  • Bug submission
  • Bug browse in a flexible table (sortable, collapsable)
  • Full extensible bug description model, using a form element editro for adding contextual criteria
  • Introduced a formal workflow for the bugs using a new state machine : Posted -> Open -> Resolving -> [ Blocked (by another issue) ] -> Resolved OR Abandonned
  • Bug dependancy (lightweight) implementation
  • Comments on bugs
• Bug search
  • multicriteria search supporting contextual criteria
  • Query storing capability
• Notifications
  • Mail notifications on state changes
  • Subscriptions for notifications
  • Personal profile for tuning how and when I am notified (watches)
• User model and Capabilities
  • All user model is ported to the new capability system of Moodle
  • Four major capabilities, denoting of power of participants : Manager, Resolver, Developper (potential resolvers), Reporter
  • Managers can assign bugs to resolvers taken within available developpers
  • Managers can register/unregister developpers
  • Resolvers can edit bug properties and post resolution
  • Resolvers can assign back a bug to a Manager, in case they do not know how to conclude.
  • Resolvers can assign to another resolver in case it is allowed in configuration.
  • Reporters (typically all authenticated users) can browse and report issues
• Other recodings and miscellanous
  • Full language packs EN/FR/ES
  • Full backup/restore
  • Global reports
  • Finishing complete Moodle API implementation (participants, recent activity, etc.)
  • Should we think about grading this activity ? ?
  • MVC construction, full redrawing code.
  • Full tighened forms (not using new form lib yet, sorry, but I still have to put an eye in it...)
  • Shareable criteria over a course (default) and across courses (sitewide form element sharing)

I think that's all, folks ! For the first milestone...

Thanks Tim, I saw effectively, but there is always an operational value to have commented API so we do not have to dig through the code to see what it is on.

Effectively, I used assessment/lib.php as template for getting through the flexible_table.

May I have some (so little) time to publish a docuentation on that API... (Why are not day/night hours exensible ? )  

Gracias Alfonso.

Siempre es muy valoroso de buscar a los ultimos errores. Asi llegamos juntos a mejorar nuestra herramienta mayor con el exito de una collaboracion internacional !!

Que te vaya bien !

Valery.