Hi Hans, it´s a great motivation for us if people start using the system and change/extend it to their needs (and also let us know).
> Hans, > > thanks a lot for sharing your approach of integrating Chamilo with Matterhorn > in such great detail. Especially the parts were you were successful and/or > hit a rock are of great interest to us and will help us improve where > improvement is needed most. > > Inline a few comments on specific paragraphs: > > On 21.04.2011, at 20:44, Hans De Bisschop wrote: > >> 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. > > Work on a plugin architecture that would allow player plugins to consider 3rd > party mediapackage elements has been started but needs to be improved a lot. > This should provide you with more flexibility when it comes to displaying > content using the engage player. Plan is: Keep the flash based video representation as independent as possible from the rest of the engage part and fire the commands over an API (bridge) to the part of the page that presents the video. There is no strict Flash-based application. If you look closely ;) you´ll see a HTML based structure for the video communication that needs its <video> counterpart (addition flavors/workflows) that can reuse the rest. It´s on our agenda - but help is welcome! (plugins, flavor detection and design work). Major goal was multimedia accessibility, platform independence and a multiview video support that allows to sync different content streams without a huge waste of bandwidth. I would be happy if you could tell us more about the problems with the feeds. > >> 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. > > If you don't mind, I would be interested in detail why you weren't able to > make this happen. I am not aware of any places in the code where we are > explicitly filtering out source flavors. > >> 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. > > Authorization is well underway and an initial implementation should be > completed by May. It uses XACML in order to continue our efforts to provide > data exchange based on standards. > >> 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. > > I think you took the right approach. We expect the list of workflow > operations to increase over time, together with the configurability of the > existing ones. Unfortunately, we are not completely there yet :-) > >> 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. > > Alternate sizes of the same media should be possible already and are used by > Osnabrück's production version of the engage player (should make it to trunk > soon). Already in trunk Hans (rev: 10328) http://opencast.jira.com/browse/MH-7632 > An archive is needed by many other institutions, too (though it is unclear > how "visual" the first incarnation will be). As for the interactive drag and > drop workflow and encoding profile builder: Unless you have something in mind > already, that dream might take a while to come true... > >> 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 ... > > Hans, please keep sending status updates like this, it is some of the most > valuable and detailed pieces of feedback that we have received so far. +1 > > Tobias Thanks Markus > _______________________________________________ > Community mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/community > > > To unsubscribe please email > [email protected] > _______________________________________________
_______________________________________________ Community mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/community To unsubscribe please email [email protected] _______________________________________________
