Thanks, Christoph! Of course, your answers lead to further questions: > adding a media package to the episode service is just a regular workflow > operation. So it depends on where you put it into your workflow. Currently > I've added the "add to episode service" right before cleanup in the standard > "compose-distribute-publish" workflow so an episode comes available at the > end of a successful processing. Interesting. So what happens if you run a workflow that has an "add to episode service" operation on a mediapackage that has already been added to the episode service? Does it show up twice, or is there logic in place to prevent that?
>> Can you have multiple workflows simultaneously running against the same >> episode? > This depends on the actual workflows. Take for example metadata changes > happening concurrently in both workflows. That leads to lost updates of > metadata. How will we prevent the running of a workflow that could cause such a problem? I tend to agree with Ruben that we shouldn't allow simultaneous workflows on the same mediapackage, but otoh I can imagine use cases where there's an urgency and thus a need to start a workflow on an existing mediapackage asap. Quite complicated. Probably safest to not allow in early iterations. >>> -my understanding is that the episode list in the UI mockup represents >>> recordings not workflow instances. If so, workflow info like the "process >>> column" should be removed in light of this, as there is already a place to >>> review workflow instances. This makes sense especially if simultaneous >>> workflow instances are running against the same recording. > It represents media packages aka episodes in their most recent state. As the > term recordings is currently used in the UI it is a synonym for workflow > instance, isn't it? No, not really. The term "Recordings" is meant to be meaningful to ordinary program administrators. Here's how I've explained it previously: >>>>> When the current admin UI was designed with the term "Recordings", it >>>>> was with the intention of "Recordings" being a reference to something >>>>> more conceptual than a single workflow instance. It was meant to >>>>> represent the conceptual entity that non-Matterhorn technical experts >>>>> might think of (and care about) when they're asking questions, e.g. "When >>>>> will I be able to view [the recording of today's class]?", "What has to >>>>> be done to make the [the recording of yesterday's class] available?". As such, it encompasses both mediapackages (the "stuff") and workflow instances (the actions run on that "stuff"). Since we haven't been able to apply more than one workflow to a mediapackage in the past, this has more or less worked (i.e. there's been a one-to-one mapping between mediapackages and workflow instances. Personally, I always thought of "recordings" being somewhat more closely aligned to mediapackages and it seems I'm not alone.) No longer do we have that one-to-one mapping, which is why we are running into issues. > In this scenario the "process column" makes sense since it gives the user > direct visual feedback about what he has done after starting a workflow with > some episodes. Please see also http://opencast.jira.com/browse/MH-8124 It does make sense, though Adam is hinting at one more piece of potentially redundant information. (That is, if we *really* want the current Recordings UI to represent workflow instances, we'd want to add a column there naming the workflow selected.) To me, this is highlights the inherent confusion in having both a Recordings UI and an Episodes UI. How are users going to know which is which (where they are) and what the relationship is and when they should go to one rather than the other? The two UIs have a whole bunch of columns and other controls that are the same... *If* we keep the Episodes UI as is (for the short term), at the very least I'd suggest renaming the column (half-baked ideas: "Now running" or "Current workflow"). >>> -If a workflow is chosen and it needs options set prior to initiation (i.e. >>> flavor identification) will the user be presented with required options >>> prior to worfklow initiation? I could see a scenario where the user >>> originally ran the default workflow with a subset of avail options and >>> later they want to run the same workflow with other options chosen. In the >>> context of the episode UI, it might make sense to have granular workflows >>> in place that don't rely on options. > Good point. We need to think about this. Yeah, I was wondering if this is going to require different "types" of workflows, i.e. the fairly complex ones that are available when a user first schedules or uploads a recording vs. the simple, granular ones that are run on existing mediapackages. Somehow seems overly convoluted, but I don't really know... >>> -which date is represented in the date column? upload date? creation date? >>> > Currently this is the start time, which is the creation date. Creation date of the mediapackage? Please remind me when the mediapackage is first created: for scheduled recordings, is it when the scheduling happens or when capture starts or when the media is ingested or...? > One thing I like to get clear is the definition of "recording", "workflow > instance", "episode", "media package". As far as I understand it "recording" > equals "workflow instance" and "episode" equals "media package". Thoughts? Agreed that we need to come to agreement on how we use these terms. I do think we need to keep in mind, however, that the UI terminology shouldn't necessarily match the underlying system terminology or even necessarily have an equivalence. The first of the four terms is a UI term (meant to be meaningful to users), different from the rest (which map to the system implementation). It does seem that "episode" = "mediapackage", so I'm wondering if we need to continue to use both. > Judy Stern Educational Technology Services, UC Berkeley [email protected] _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
