Judy, again, answers and comments are inlined.
>> 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? The media package replaces -- which means updates -- an existing one. As long as concurrent processing of a media package is prohibited this causes no problems. >>> 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. I think that should be in the responsibility of the workflow service. I'll ask Tobias/Josh for their opinions about this. >>>> -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"). I think the current recordings UI which deals with workflow instances provides a view more suitable for system administrators who want to know on a lower level what's currently going on, why errors did occur etc. The episode centric view however, is for the content manager who wants to know what's part of the repository, who wants to edit metadata, republish episodes or retract them as needed. >>>> -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… A more complex task that we should postpone for now. >>>> -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...? I'm sure it is when capture starts, but I'll ask Tobias. >> 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. We maybe shouldn't mix terminology in one conversation except if the terms itself or the subject. Christoph > > 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] > _______________________________________________ _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
