Ruben & Christoph, I really appreciate the detailed discussion on this.
My hope is that the proposal enables Matterhorn to distinguish between an element's publication protocol, like RTMP, and the element's file manipulation protocol, like HTTP, SCP, FTP. The distinction would enable Matterhorn to uses a publication protocol when presenting media to a user through a UI, and to use a file manipulation protocol when performing tasks like archive, update, delete on the media. Right now (1.4rc2), when Matterhorn copies files into a local distribution directory, it only knows that those files are accessible through the presentation protocol. Both media presentation and file manipulation are attempted through the same single presentation protocol. This is a problem when the presentation protocol does not support file management tasks like copy, update, and delete. It's not a problem if the protocol if the presentation protocol can do both. RTMP streaming protocol cannot do both. In Vincente's presentation on PDP Architecture, I especially like that the user has one way to access media as prescribed by the metadata in the publication, and Matterhorn has a different way to access the media. Matterhorn can use its own file management protocols, separate from those in the publication metadata. The following is my interpretation of the PDP Architecture, from Vincente's presentation, for Matterhorn. 1) When Matterhorn performs Distribute, it copies actual files from the temporary working directory (or archive) to a distribution location 2) When Matterhorn performs Publish, it sends a selection of metadata, including logical links, mime-types, access protocol, to a publication service/entity/channel/engage server. 3) The mediapackage remembers where actual files were copied to and what protocol was used to put them there. It also remembers what protocols and paths are used to display a publication. It has a distinction between file management and publication display references/distribution channels. 4) A user accesses distributed files with the protocols supplied by the publication channel. 5) Matterhorn is smart enough to use the presentation protocol when presenting media to a user through the GUI. Matterhorn uses a file management protocol and paths when managing files for archive, recall and update from the distribute location (it it has rights to do so). > 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. Agreed, it would be helpful to cross-reference distribution information and presentation/publication information in the mediapackage manifest, catalogs, (or database?). Then, when distributed media is updated or deleted, the related publications can easily be found and appropriate action can taken with them. > What we *really* should do is keeping the internal URLs of all the assets in > a MediaPackage while we also have the URLs from where such assets can be > accessed from the outside (if there are any), which is all this proposal is > about. Yes! It would be helpful for internal URLs to be maintained in the mediapackage. I will wait to hear more details on Christoph's comment for maintaining some coordination data only in the database. I don't understand why the mediapackage should know less about its publications than the database. - Karen
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
