Hi, Chris: I'm glad to get your remarks. Comments are inline.
2011/9/6 Christopher Brooks <[email protected]> > Hi, > > Just a couple of thoughts, > > > I strongly believe that those migration problems are perhaps caused > > by a too-twisted treatment of the recordings and the workflows in > > matterhorn. In the current philosophy, "workflow" is just a certain > > way of seeing a mediapackage, while the search results are another > > I wouldn't quite say this. I'd say that a media package is a > data structure, a workflow is a function, the results of running a > workflow are a bunch of other data structures, and that there is not a > clear link between the input data structure (media package) and the > output data structures (indicies, media files, distributed files, other > service calls, etc). > > When you upgrade matterhorn you may change the workflow (intermediate > function). > > Note that the function can take an identical mediapackage but result in > different output data structures. There is no garuntee that the > function is a one way mapping. > I was trying to reproduce some words Josh wrote to me once, but I may have failed to do so. Apologies to him I misunderstood, and, well, maybe not everyone shares his vision anyway. However, I agree with you in most part, except in that "there is not a clear link between the input data structure and the output data structures". There is not a clear link because Matterhorn is not designed for it to be, but it would be clearly easier if there was. Matterhorn is about media, so the most important thing are media files (and metadata files), and the rest (indexes, function calls) are just means for the system to work. Therefore, we should see a workflow as a black box where a mediapackage comes in and goes out modified somehow. For instance, a raw mediapackage with source files (and metadata, I insist) goes in, and a *complete* mediapackage with media files for downloading, watching online, etc. AND the original media files (or not, depending on what we want) goes out. The distributed media files should still be a part of the mediapackage BECAUSE they are a different version of the same source media. > > relates all the files of a mediapackage--, so that you just cannot > > get a complete picture of the mediapackage altogether. I strongly > > believe that we should see the mediapackage as a list of related > > files including media, metadata and attachments TO WHICH you can > > I think the episode service is looking to do some of this. That said, > I don't think anyone has suggested that published media is tied in any > way to the originally ingested media package. Without this things like > URLs will continue to change, and that remains a pain point for folks. > I am suggesting that. If distributing to some channels, like iTunes, requires submitting a copy of the video to somewhere out of our control, at least Matterhorn should be aware that there's a distributed copy and allow synchronization of that copy with any changes that are made within our system. I don't think this is a lot to ask: some proposals and suggestions have already been made to being able to synchronize, for instance, a change in a certain recording title with the title in some or all of the channels where it's distributed. It makes sense if we stick to the abstraction that all related media files (sources and files derivated from them) ARE in the same mediapackage. > > mediapackages at the system, to which you can apply different > > workflows, thus modifying the number, type, flavor, metadata, etc. of > > the files in the mediapackage. 2) Everything is centralized: the > > mediapackage flavors can tell you which files were the originally > > How do you manage distributed artifacts as part of the media package? > E.g. something we publish to itunes? > How do you manage distributed artifacts now? As far as I know, you can't -- I mean, you can't *from Matterhorn* (obviously you can go to iTunes and manage them from there). But, let's say we have a mediapackage with some distributed files, which ARE actually there (somehow you inspect the mediapackage and you can see some files distributed to iTunes, for instance with the flavour "presentacion/itunes" --remember that a file in a mediapackage is little more than an URL in an .xml file or in an index--). Then you want to modify the title. You go to your mediapackage and modify it, and that should trigger a workflow that, using the ITunesDistributionService REST services will modify the title in iTunes accordingly. If, instead, the workflow results are different files scattered along different distributing channels with no relation between them, it is really tricky to get to the distributed files from the source mediapackage, if for instance you want to make modifications in ALL the channels to which a certain recording is distributed. Chris > -- > Christopher Brooks, BSc, MSc > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > Matterhorn mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > [email protected] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
