Sorry if it seems I'm repeating myself, but I don't think I completely understood some of your answers. Please find my comments below.
Regards P.S: Apologies for the long rant :S. Rubén Pérez Vázquez <http://www.teltek.es> www.teltek.es 1) How do we deal with the fact that several "versions" of the same >> MediaPackage can be distributed to the same distribution channel? For >> instance, I'm thinking of one Youtube video with just the slides (and the >> sound) and another with just the teacher. Or one with the slides and the >> sound and another with a composition of the camera and the slides. Will we >> have, then, two (or more) "presentation" elements? > > > That's the idea. We thought about introducing sub-representations but then > decided to keep it as simple as possible. The distribution channel is able > to store what was distributed in the <dict> part of the element, so it is > easier to retract. In addition, there will still be the "type" element > containing the flavors, so this could be used to indicate the distributed > content as well. So, just to clarify, suppose we are distributing two versions of the same mediapackage to the same channel. The resulting presentations section would be: <presentations> ... <presentation id="p-1" channel="some-channel"> <uri>prot://my.fancy.uri/this/is/version/one</uri> <mimetype>some/mime</mimetype> <dict> <value key="some-key">sOmEvAlUe</value> ... </dict> </presentation> <presentation id="p-2" channel="some-channel"> <uri>prot://my.fancy.uri/this/is/version/two</uri> <mimetype>other/mime</mimetype> <dict> <value key="other-key">oThErVaLuE</value> ... </dict> </presentation> ... </presentations> or <presentations> ... <presentation id="p-1" channel="some-channel"> <uri>prot://my.fancy.uri/this/is/a/common/path</uri> <mimetype>some/mime</mimetype> <dict> <value key="version-one">key-to-find-version-one-in-the-channel </value> <value key="version-two">key-to-find-version-two-in-the-channel </value> ... </dict> </presentation> ... </presentations> > 2) I don't like the name "presentations", because it may be confusing with >> the term "presentation", often used to refer to the PowerPoint presentation >> ("slides") used in a recording. Due to the lack of a better term, I'd >> suggest "distribution", which in the end is the term used to describe what >> this new MediaPackage item is for. I'm not very sure about this last name, >> but I do think it's more accurate and ledesign has two different steps to >> make media available to the outside world: ss confusing than the proposed >> "presentations". > > > I agree and disagree as we were discussing presentation vs. distribution > as well. The reason for sticking with "presentation" in the proposal was > that distributing a file (e. g. to the download server) is different from > presenting it (e. g. on a video portal or in feeds). In fact, multiple > representations may be based on the same distribution. The term is still ambiguous in the sense that it's been used (and is being used) with a totally unrelated meaning in a different part of the system. But I believe there are much stronger reasons against mixing presentation (a.k.a. publishing) and distribution under the same category. Please see below. > 3) I have just realized of the "channel" argument in the second example >> given by Tobias. Shouldn't we make a difference between elements >> distributed as "downloads" and as "streaming"? In that case, "engage" would >> be an ambiguous term, and we should specify 'channel="engage-download"' or >> 'channel="engage-streaming"' (or, at least, 'channel="download"' or >> 'channel="streaming"'). I know those are mere examples, and not "real" >> pieces of xml, but I think it's good to point this out and make it clear. > > Again, the presentations should be differentiated from the file > distribution. If this proposal is accepted, it would probably be up to the > presentation services (e. g the search service aka engage) to use the > distribution services to place the files rather than the workflow randomly > throwing files onto the download server. Every presentation instance would > need to make sure that the files or streams they are representing is in the > right place (and removed if retracted). So as a result, distribution would > be a responsibility of each presentation channel. I think the workflows are no more "randomly throwing files onto the download server" than the Youtube service is "randomly storing files at some external server who-knows-where". The distribution service knows which elements are distributed simply by inspecting their URL. That doesn't mean we cannot be more explicit about the state of "distribution" of the Mediapackage elements, but it doesn't make it "random" either. That being say, I think the proposal is lacking a clear way of defining relationships between *published* elements. If we agree that the URL that opens a certain Mediapackage in the engage player is a *presentation*, then we *must* agree that the URL from where the media is fetched in the download server is *also* a presentation, because any user can download the files directly without using the Engage player at all, or maybe stream them directly using, say, VLC. For instance, we should end up with, at least, three *presentations* if we publish a Mediapackage at the engage server via download: one entry for the presenter file at the download server, another for the slides video at the download server, and another one for the URL to the video in the Engage server. But this last *presentation* depends on both the others in order to be available. Therefore, no matter if the publishing services take care of triggering the distribution of the relevant media (which involves modifying the current services and implement ways to *decide* which type(s) of distribution they will use) or the workflows distribute the media explicitly, we must be exhaustive with all the kinds of *presentations* a MediaPackage has, or at least state explicitly that the Engage Service (or rather the download and streaming services) are an exception. And, still, in the case we go with the refactoring of the publishing services to manage the distribution of the media, we need a way to coordinate between different publishing systems using the same distributed media (several *publications* accessing the same resources via the download server, for instance). > Tobias > _______________________________________________ > Matterhorn mailing list > Matterhorn@opencastproject.org > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > matterhorn-unsubscr...@opencastproject.org > _______________________________________________ >
_______________________________________________ Matterhorn mailing list Matterhorn@opencastproject.org http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email matterhorn-unsubscr...@opencastproject.org _______________________________________________
