Hi Ruben,
find comments inline.
Am 06.02.2013 um 03:34 schrieb Rubén Pérez <rubenpe...@teltek.es>:
> 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>
The first one is it.
> 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.
I see your point. An alternative to "presentation" may be "publication".
> 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.
The idea with the "presentation/publication" element is different. It is
intended to describe a _logical_ presentation of the media package und should
_not_ deal with technical or implementation details like where to find the
actual media files. So in the case of Engage there's only one element, like
there would be only one element for YouTube. Take the YouTube example: Here
there would also be no reference to the actual media file. This is totally
subject to YouTube presentation layer to create the page to view the video in a
way that the embedded player knows where the media is located. This should be
the same with Engage. The entry only points to the presenting page. How the
player then knows where to fetch the media files from is an implementation
detail that should not be handled by the media package structure. That being
said the search index needs to expose the URLs to the media files seperately
now. Currently (if I'm not totally wrong) the URLs are parsed from the returned
media package XML. But that's acutally a design flaw and should be corrected
anyway.
> 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).
Right. If multiple channels want to share data they need a way to synchronize
on them in terms of distribution (copying files to some place) and retraction.
But that's an implementation detail which the channels being involved have to
solve. I imagine a DB bases synchronization here.
To summarize again:
Our proposal deals with _logical_ presentations only, not the technical and
implementation details. In fact we try to move them out of the media package
structure and make them subject to the channels. This is gives much more
clarity and is an overall design improvement IMHO.
Hope that helps,
Christoph
_______________________________________________
Matterhorn mailing list
Matterhorn@opencastproject.org
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
matterhorn-unsubscr...@opencastproject.org
_______________________________________________
