I'll echo Tobias' comments by thanking you for sharing your experiences. More comments inline...
On Thu, Apr 21, 2011 at 11:44 AM, Hans De Bisschop <[email protected]>wrote: > 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. > Please feel free to submit one or many "Community Feature Request"s in our Jira issue tracker [1]. We've tried our best to make Matterhorn easy to integrate with, but without real integrations, we're only guessing. Requests from developers doing real integration work is the best way for us to improve things in future versions. > > 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. > Only the video pane is Flash, the controls are JavaScript + HTML + CSS. The flavors chosen for the player are defined in Javascript, so can be easily modified. If you have ideas for improving on the flexibility here, please do let us know. > 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. > You can modify the existing feed configurations, or add more feeds, by changing the *.properties files in $FELIX/conf/feeds/. Setting the track flavors is as easy as changing this line: feed.rssflavors=presentation/delivery,presenter/delivery If you need more flexibility such as, for example, changing the track flavor based on a query parameter, please let us know the details of what's missing. > > 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. > Adding a "publish" tag to the source media tracks didn't work? If that's the case, please file a bug. The publish operation should publish any mediapackage element with the configured tag. > > 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 > ... > > Thanks again for sharing. I'm looking forward to seeing what you can do with the current system, and how upcoming improvements in Matterhorn might help you and other integrators in the future. Josh [1] http://opencast.jira.com > 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] | www.erasmushogeschool.be > > Kom eens langs: www.erasmushogeschool.be/infodagen > of lees onze elektronische nieuwsbrief: ehbrief.ehb.be > P Before printing, think about the environment > >
_______________________________________________ Community mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/community To unsubscribe please email [email protected] _______________________________________________
