Hi all,
It's been a while since I posted about our plans to implement an
integration of Matterhorn for the Chamilo 2.0 (learning) content
management system. Ever since that initial post, a lot of progress has
been made, so I figured it was time for an update.
As mentioned previously Chamilo 2 relies on a so-called "exteral
repository"-framework to allow integration of a variety of external
content sources. (Right now support is limited to bitbucket, box
dropbox, fedora, flickr & 23, google docs, matterhorn, mediamosa,
photobucket, picasa, slideshare, soundcloud, vimeo, wikimedia, wikipedia
and youtube ... but support for even more services and protocols is in
the pipeline)
A few months ago we got the go-ahead for a sizeable project disclosing
part of the audiovisual archive of the Royal Conservatory of Brussels
and the "RITS" (audiovisual and performing arts) attached to providing
audiovisual resources for distance learners as well as regular students.
We started having an even closer look at Opencast Matterhorn to
determine what makes it tick and how much of what we need was there and
if and where we needed to provide some extensions.
Considering the modular nature of both our own software and Matterhorn
we quickly divided the integration into 2 big flavours dubbed
"Matterhorn" and "Chamilo" based on where the media packages would be
indexed. Yes, that's right, Chamilo can also act as a search index for
Matterhorn's back-end. Why did we choose to implement this option? First
of all let me say that the integrated Matterhorn indexing is fantastic
and the media module is a great tool. Sadly enough (although quite
logical) there were also a few things missing from it in our opinion.
Firstly the media module engage player is a strictly Flash-based
"application", which is not even aware of any other kind of "flavour" of
the track that might exist. The same goes for the RSS / Atom feeds, with
a different media-flavour obviously. Support for as many platforms as
possible was "expressed" to be important and considering recent
evolutions in terms of HTML5 it's understandable as well. Strike one for
the easy integration.
Secondly ... out of the box Matterhorn's search index does quite a bit
of filtering on the original mediapackage as it is produced by the
workflow. It can be configured to some degree, but some things will get
"lost" in the index. Most notably the "original" track, which is
archived but not accessible any more. Availability of individual tracks
can easily be manipulated by adding / removing tags as needed, but this
turned out to be impossible for the source media. Strike two for the
easy integration.
Thirdly we need advanced rights management for individual tracks of a
mediapackage. I'm personally not a fan of it and would prefer everything
to be more open, but it's just one of those realities from which there's
no escaping. This means we have to be able to configure whether someone
can download the original source file and if needed/wanted which
additional versions he can watch / download. This would basically mean
copying and synchronizing a ridiculous amount of data between both
systems, which seemed rather silly. Strike three and you're out.
Still, the first thing we did was implement an integration which is
limited to what an out of the box Matterhorn installation can do via
webservices and it's media module and search index. This includes
uploading / ingesting recordings from within Chamilo 2 to Matterhorn,
browsing published media from within Chamilo, "importing" links to a
mediapackage allowing users to watch an HTML5-based version of the media
(when available) or a fall-back to the embedded version of the engage
player. Other simple actions include listing workflows, deleting media
from the search index and editing some metadata by means of a few tricks
(since direct editing isn't possible quite just yet). Works
fantastically without any changes to Matterhorn whatsoever, although we
obviously defined some custom encoding profiles and workflows for the
HTML5 stuff. No information whatsoever about the mediapackage is stored
in Chamilo, apart from it's identifier of course.
But did I mention we needed / wanted more? That brings us to the
"Chamilo as search index" modus of the integration. The one part that
doesn't really change in this modus is the uploading. Users still simply
fill out a form when they want to upload something and submit the form.
What happens afterwards is somewhat different though. Instead of just
sending everything off to Matterhorn (and later on accessing it via the
browser), we already add an initial representation of the mediapackage
to the user's personal Chamilo content repository right before we tell
Matterhorn to start the workflow. This mediapackage obviously doesn't
really contain anything yet. The fact that it is there though, combined
with a check whether workflows have been instantiated and/or are
running, does let the user know something is actually happening. At this
point all available information about that basic mediapackage has
already been stored in Chamilo.
At the same time we can't simply wait for Matterhorn to finish the
entire workflow before adding the mediapackage to the user's own
repository. Even at record speeds that could take minutes and end users
tend to not like staring at a semi-static screen for that long. So once
the workflow has been started, the user can just go about his usual
business in Chamilo. So the next thing we needed to do was to get the
finalized mediapackage back to Chamilo. In a way it can easily be
compared to the distribution and/or publication operations. Initially we
looked at the distribution operation with a possibility to write a
Chamilo extension for it (just like YouTube and iTunes U). Sadly enough
the distribution framework seemed to be oriented more towards the
distribution of individual tracks, rather then the entire mediapackage
and we did not want to start modifying that at all. It was close but not
close enough.
The publish-operation seemed like a much better much, considering that
it was actually publishing the media package to Matterhorn's integrated
Solr-based search index. That's exactly what we needed: a way to send
the entire mediapackage manifest back to Chamilo. This made us decide to
write A. a new ChamiloWorkflowOperation, which can be added to a
workflow and will actually trigger B. the ChamiloService module. The
ChamiloService is a fairly simple module given that all it needs to do
is take the entire, finalized mediapackage from the workflow and send it
to Chamilo by means of a "simple" post.
At that point it's up to Chamilo to process the entire XML-manifest and
update the mediapackage which was stored internally before. At this
point the user will also be notified by e-mail that his media is
"available". Visually there will not be that much of a difference
between both methods of hooking up Matterhorn initially, but quite a bit
of advanced functionality still has to be implemented. A.o. extensive
editable metadata, alternate sizes of the same media (a la YouTube I
guess), an audiovisual archive with configurable access to specific
versions of media, etc. Our "dream"-list contains such things as an
interactive drag and drop workflow and encoding profile builder.
It's still very much a work in progress, but we're pretty excited by the
way Opencast Matterhorn has made all this possible in a rather painless
way (unlike some of the other systems out there). It's a pretty compact
summary of what we've been doing, so if anyone has any more questions,
just shoot ...
Best regards,
*Hans De Bisschop*
Hoofddeskundige ICTO |Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 |B-1070 Brussel
T 02 559 02 54 |i 254
[email protected] <mailto:[email protected]>
|www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
PBefore printing, think about the environment
_______________________________________________
Community mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/community
To unsubscribe please email
[email protected]
_______________________________________________
