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.
> 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). 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.
Tobias
_______________________________________________
Community mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/community
To unsubscribe please email
[email protected]
_______________________________________________
