After I finished my previous post, I recalled a few moments when things didn't work the way I wanted (or didn't work at all). One thing led to another and I start thinking what were the main challenges I faced during this project. If I was to make such a list, it would be probably look like this:
Don't modify this file unless you know how it works
Anyway, even with all these issues, finishing this project was never at risk, because Jerome was very helpfull and quick in response, providing me with usefull tips, coding help and great feedback, and occasionally collecting feedback and advices on my befalf from other Moodle developers. He's also very pacient and he gave me a lot of freedom to work on the project on my own pace.
Dongsheng (who designed and developed the repository API) was also very supportive, helping me when I got stuck with the repository API and quickly fixing repository bugs so that I can move on.
Last, but not least, Helen was very helpful with the administrative part, keeping me (and the others) informed and focused on my schedule, stepping in on a few occations to make sure I have a great (and complete) GSoC experience.
During Google Summer of Code 2009 project I worked on implementing repository plugins that would allow users to record audio files directly into Moodle. Initially, the plan was to provide a single recording only, but things went a bit further, and I also implemented a collection management feature.
Both plugins have integrated help pages for all their features, but additional help (mostly for developers) is in the Record audio repository plugin wiki page. Some discutions focused on audio and/or video recording in Moodle are in the Record audio repository plugin (was Wanted: New feature ideas for GSOC projects) and GSOC: Record Audio/Video directly into resources/activities forums. The later is more general, not only about the repository plugin. Last, but not least, there also a place for feature requests and bug reports in the MDL-18341 ticket.
The plugins are not included in the Moodle releases (not even the 2.0 dev daily build). In order to test them, you'll need to use a 2.0 dev daily build.
The Riffly plugin allows audio-only or audio-video recording inside the Moodle repositories. The flv files are stored on riffly.com servers and, optionally, they can be downloaded into Moodle (to go under Moodle File API control). Recorded files and the recording flash object is available in all places where the repository is used to select files.
After you download a Moodle 2.0 dev build, you'll have to download the plugin manually from CVS and copy the entire riffly folder inside the repository folder of your Moodle instalation. Then go to the Plugins/Repositories entry of the Administration menu, enable the plugin and make it visible. When you're done, you'll have the option to create riffly site-wide, course-wide or per-user collections. For each collection, you can choose what type of content it accepts: audio, audio-video or none of them (to get a locked collection).
The Nanogong plugin allows audio-only recording inside the Moodle repositories. The wav files are stored into Moodle using the File API. The sound files can be recorded using the ImaACPCM or Speex codecs. As for the riffly plugin, recorded files and the recording applet are available in all places where the repository is used to select files.
After you download a Moodle 2.0 dev build, you'll have to download the plugin manually from CVS and copy the entire nanogong folder inside the repository folder of your Moodle instalation. Then go to the Plugins/Repositories entry of the Administration menu, enable the plugin and make it visible. When you're done, you can select the codec used and the quality of the sound for the site-wide recording instance. This instance will be shared by all users of your site (because it only handles recording, and File API handles the rest).
This is a compilation of the notes I tookon nanogong appet. I think I got everything here and I didn't missed anything.
The nanogong applet accepts the following (optional) parameters:
Appart from SoundFileURL and Start parameters, which allow sound to be played as soon as the applet is loaded, the nanogong applet can be controlled using the sendGongRequest method. In order to do this, the applet should have an id, which makes it easy to get a reference to it in JavaScript. Here's an example:
HTML:
<applet id="nanogong" archive="nanogong.jar" code="gong.NanoGong" width="180" height="40"></applet>
JavaScript:
var recorder = document.getElementById('nanogong');
if (recorder == null) {
alert("recorder not found");
return;
}
var result = recorder.sendGongRequest(...request name..., ...parameters...);
The following requests names (and parameters) are accepted (including returned values, but without quotes):
Here's an exemple that also uploads the registered message (2 files in the same directory):
File: record.php
------------------------
<?php
if(isset($_GET['save'])) {
move_uploaded_file($_FILES['sndfile']['tmp_name'], '/tmp/' .
$_FILES['sndfile']['name']);
echo 'Your file have been saved.';
exit;
}
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>The NanoGong Applet</title>
<script src="nanogong.js" type="text/javascript" language="javascript"/>
</head>
<body>
<h1>The NanoGong Applet</h1>
<applet id="nanogong" archive="nanogong.jar" code="gong.NanoGong"
width="180" height="40">
<param name="AudioFormat" value="ImaADPCM" />
</applet>
<input type="button" onclick="sendFile('nanogong')" value="Send" />
</body>
</html>
nanogong.js
------------------------
function sendFile(applet_id) {
var recorder = document.getElementById(applet_id);
if (recorder == null) {
alert("recorder not found");
return;
}
var duration =parseInt(recorder.sendGongRequest("GetMediaDuration", "audio")) || 0;
if (duration <= 0) {
alert("no recording found");
return;
}
// upload the voice file to the server
var msg = recorder.sendGongRequest("PostToForm","record.php?save=1", "sndfile", "cookie=SomeText", "myfile");
alert(msg);
}
The problem with the current applet is that it is not signed and it contains code for saving files locally. This makes browsers to ask the user if they trust the applet publisher. This is annoying and it may raise concerns for unfamiliar users. There are three solutions to this problem:
The riffly plugin repository is almost completed. Jerome is helping me with QA and squashing bugs. The plugin now supports multiple instances (per site, per course and/or per user) and each of this instances can be setup to support only audio media, only video media or audio and video. Also, each instance can be setup to download the riff files locally (for management using Moodle's File API) or to link to the files on riffly.com (very useful, if you have limited storage space or bandwidth).
Meanwhile, I started work on the second plugin, which is using the Java applet nanogong.
This week I "finished" the repository plugin for integration of riffly.com web services. I got carried away so I added more features than I initially planned for (like video recording). Before going into more details, you can go and download the plugin from the ticket #MDL-18341.
Instalation: Inside the tgz'ed file you'll find only one folder (called riffly) that you'll have to extract in the repository folder of your Moodle instalation. After that, go to Moodle's Site Administration menu and drill into Plugins/Repositories/Manage repositories. Click on the "Add Riffly" link and then enable the Riffly repository plugin.
Usage: As I said, the plugin has many features (although some of them are not as visible as they could be), so I will not present them all and let you discover them by yourself. Just a few tips:
Things that might go wrong: The code was developed against the HEAD of Moodle's CVS and it works ok. However, I spent an entire day tracking down a bug that prevented the file picker to show its content (repository categories and items). It seems a bug found its way into commit 1.19 of lib/form/editor.php (Petr was so kind to help me find it). Either check it was fixed in a following version or use the 1.18 version from HEAD.
Things that didn't go as planned: I broke my Moodle working enviroment twice this week with CVS updates. It's normal for a product in development phase, but that doesn't make it less annoying.
I planned to create a TinyMCE to ease the proces of recording (and open the file picker directly). I never developed for TinyMCE before. I got maybe 60% of it done, but yesterday I got stuck in some JavaScript issues. Today, I found some ways to make it work, but I'll have to postpone work on it for a while.
Because of the TinyMCE plugin, I didn't have time to write the text filter, which would be probably much more easier and straightforward (I went with the challenging/fun part).
My short trip to Iaşi is over. I attendend the ECODAM 2009 Doctoral Summer Workshop. There I assisted to some very interesting lectures (both from invited speakers and from other PhD students) and I also gave a talk about bonds representations in Ising spin glasses.
Unfortunatelly, last moment problems before leaving stopped me from submitting the last week's work summary and once got there my online time was very limited (between lectures, organizing activities, and spending time with my favorite niece). Therefore I'll do a two week summary in one post.
I finished the code for retrieving riffs metadata from Riffly. This is used when the user manually adds a riff to the repository.
I refactored the JavaScript code for integration of Riffly callback API with Moodle. It's much cleaner now, using AJAX POST to send the data back to Moodle repository and callback functions to update the File Picker location only if the riff ID was correctly stored in Moodle. If the store process fails, the the File Picker location will not change, so the user will be able to retry.
One problem that gave me major headaches (especially because I didn't have an Internet connection to search for more data) was the inconsistence between YUI's asyncRequest docs and implementation. Documentation says that the callback can be a function or an object. This is either wrong, or Moodle's YUI version it's older, because a function doesn't work. Finally I found the solution: use an object with success and failure methods.
When I updated code from CVS, I got the surprise that the HTML meta got deprecated from print_header. I was using it to inject some small JavaScript code (a hack, I know). Anyway, I had to learn about the new way to do it: using the require dynamic property of the global $PAGE variable. So now, the JS is on its own file, connection to Moodle through the riffly JavaScript variable.
Finally, I applied for write access in contrib/plugins/repository/riffly so I can start to commit.
To do: these are some ideas that might be good to implement:
The plugin I'm working on is starting to get a face, too. I almost finished the rough user interface. It doesn't have all the bells and whistles of Mihai's work, but it's enough now for testing the backend. I'll probably have to work on it some more after I get the feedback from Jerome. This is how it looks right now.
The user accesses the repository instance (in this case, called something). She/he will always see two pseudo-entries: manage collection and record. In addition to these, all the audio items in this instance's collection will be available for selection.
NB: The repository framework only supports thumbnail images for previews. This is not very usefull in the case of audio content. One of these solutions could be used:
The Manage collection entry displays a page where the collection entries can be deleted, previewed or added. This is usefull if you want to move items from one collection to another or to add an item that you now recorded.
NB: The i18n is not fully implemented and many language strings are missing.
Finally, the Record entry displays the recording Flash object. It allows users to record audio content and save it. I'm still fighting some JavaScript issue in order to automatically store riff ID and select it in the file picker after recording. This also brought me to my first contact with YUI. It's ok, but I like JQuery better. JQuery is simply more fancy, lightweight, and ... more fun.
These are some additional information I managed to obtain about the riffly.com services. First of all, the API does not offer an username/password authentication method for premium users. If a user has a premium account, they add their domain in their control panel on riffly.com, so it will auto-detect any riffs that are played from their domain.
Second, the metadata for riffs is only available though JavaScript. More exactly, imagine you have the ID of a riff: B47686169D7111DC9B0D44CF0D09CCE3. In order to get its metadata you have to read http://riffly.com/api/info/B47686169D7111DC9B0D44CF0D09CCE3, which will give you something like this:
{The most useful things here are the created timestamp and the playbacks count. Unfortunatelly, in order to display these in the File Picker, I would have to get these files for each riff and parse them in PHP. I'm not sure it's worth it.
"created" : "1196227339",
"riffly_id" : "B47686169D7111DC9B0D44CF0D09CCE3",
"playbacks" : "80",
"type" : "video"
}
A possible solution is to find the a way to embed some <script> tags in the File Picker that load JavaScript from this address http://riffly.com/api/info/B47686169D7111DC9B0D44CF0D09CCE3?callback=myCallback. The code produced by this address will call the myCallback function. Unfortunatelly, I'm not sure this will work with HTTPS Moodle instalations.
Today I talked to Petr about the plugin progress. The discussion was very useful because he pointed out that teachers are allowed to embed objects and applets, but students aren't (for XSS reasons). It seems that the current method for students to embed objects is providing a link and let the filters take care of the rest (I'll have to check that).
I haven't got a reply from riffly.com, yet. It's not urgent, because I can work on other stuff, but I was curious to get more details. I have another batch of questions ready for them, but one thing at a time.
Moving on and getting into more details proved harder, due to the gaps in the documentation. For answers to many questions I had to dig into the repository lib code and trace the control flow. I guess the code is still in working because there are many code comments left, some obsolete comments, and many non-documented functions (too many?). Yeah, and the Ajax part did make the process harder in some places.
Anyway, I got a skeleton of the plugin in place :). I still have some unanswered questions (like is the link and ref_id return types treated diferently, and how?).
the question to ask yourself is: What are the difference between java applet and web services for the final users (Moodle admin and the guy wanted to record a sound)? If the difference needs a few sentences to be explained, you can have one paragraph. If you need half a chapter to explain the difference, it probably needs distinct chapters/use cases.On a separate issue, I think Elena has an easier project code-wise, but more challenging "inspirational-wise".
