Hi Ruben, > I'd like to briefly state my general opinion here: I don't think that this > proposal is not necessary; quite the contrary, I do think that we lack the > ability to keep track of where our media has been published. What I'm saying > is that we need to be exhaustive about it, not just note down all the (so to > speak) "external references" to our media with no more hierarchy than "who > put those references there", because such references may depend on each other > in ways that "those who put them there" may not understand (or even should > not).
In order to stick to good old tradition, I can't agree with you :-) In my opinion, the mediapackage is not the place to store how excatly the distribution channel was doing its work. It is up to the channel implementation to keep track of the inner mechanics if that should be needed for retraction. The <dict> section in the presentation element already gives the channel a chance to store some metadata or information it may need to get back to. > Let me explain this with your specific example: when you distribute your > files via streaming, you *still* have to distribute those files to the > streaming server AND publish them (announce them, include them in the search > index, create some RSS pointing at the player, etc). Even though the file is > not directly accessible (downloadable), this does not change the fact that if > you retract the files from the streaming server, all the other stuff is > invalid and outdated. One of the overall design goals of the proposal is to *decouple* dependencies that had so far been interpreted into various aspects of the mediapackage, so I would not agree that there should be a dependency between the presentations. One may publish to an LMS and Engage, and even if those two presentations would rely on the same Apache or Red5 serving the files, I would not want that to be expressed in the mediapackage, because now you are storing part of your infrastructure setup in the mediapackage which may change at any time, resulting in invalid mediapackages. > I see two ways to go: > • We do not care about this interdependency. If we retract media from > the streaming server, we must explicitly "unpublish" the reference(s) to > that media, too. So this is a manual process, that will become more > complicated as the number of available channels grows. Here I see a difference in the ways we are thinking. You are talking about retracting from the streaming server. The streaming server however is not a "presentation". It is merely a helper service to Engage, your LMS and so on. So you would retract from Engage or the LMS, not from the streaming server. It is then up to the infrastructure setup to keep track of how many clients rely on a stream (for example by introducing a counter that is increased every time a service is putting the same file here. Only if that counter is down to zero, which is after all "presentation" have been retracted can the file be deleted). > • We make the distribution services notify the publishing services > about certain media being removed, so that they can "unpublish" their > references to the media. This again seems to be looking the other way. If you keep looking from the other side, the presentation services would inform the file hosting service that it no longer needs that file (because it has just been retracted). If the file hosting service receives enough "retract" notifiactions as it received "publish" notifications, it may safely delete the file. Looking forward to your's (and anyone else's) thoughts, Tobias _______________________________________________ Matterhorn mailing list Matterhorn@opencastproject.org http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email matterhorn-unsubscr...@opencastproject.org _______________________________________________
