Back to work

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:

• automatically select a newly recorded file (to save the user a few clicks);
• implement a text filter (Jerome sugested to look at the youtube filter for an example) instead of using flash objects;
• create a TinyMCE plugin to make recording easier than it is now (about 3 mouse clicks instead of the current 6 clicks).

First glimpse

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:

1. implement a way to add textual description to entries and display those instead of generic "Audio file" text
2. implement a way that plugins can render their own HTML code for thumbnail (I think this is more usefull: @todo: check this with Jerome and Dongsheng)

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.

Riffly API update

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:

{
  "created" : "1196227339",
  "riffly_id" : "B47686169D7111DC9B0D44CF0D09CCE3",
  "playbacks" : "80",
  "type" : "video"
}

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.

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.

Meeting with Petr

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).

No riffly.com reply yet

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.