Hi Christoph, A couple comments inline:
2011/9/15 Christoph Drießen <[email protected]> > Comments inline. > > Am 14.09.2011 um 13:15 schrieb Rubén Pérez: > > Christoph, Judy et al., > > It's exciting we are having this discussion. I strongly believe this is a > better approach to managing the video contents than the current one. I've > got just a couple remarks (I want to clarify that I am explaining my point > of view here, which may not be the same as the "official" point of view, > corresponding to the episode service developers): > > *Christoph said:* > >> *adding a media package to the episode service is just a regular workflow >> operation* > > > I strongly disagree with that. If we want to have a "real" repository, then > including a certain media in it shouldn't be a matter of processing it. If > "mediapackage" = "episode", then using workflow operations to include the > mediapackage in the service is absurd (because unprocessed mediapackage are > *also* episodes --or are they not? please share your thoughts). > > > Everything is a workflow operation, be it the video encoding, the preview > image encoding, the segmentation, the text recognition, the distribution and > also the insertion into the engage search index. In the end the episode > service is just an additional module which no one is forced to use, only > when you intend to use matterhorn more as a video management solution than > just a processing pipeline. > That's exactly my point: if you want to use Matterhorn more as a video management solution, then *not* everything should be a workflow. I'm thinking on the case that you have an episode/mediapackage in your system you have not applied a workflow to, or an episode/mediapackage which has just been ingested, but the workflow failed. You said that the episodes/mediapackages are included in the episode service at the end of the workflow, but why is this? I mean, why not having a complete view of *every* mediapackage present in the system, no matter its state? The episode service can provide that can of access, but then you shouldn't need a workflow to include a mediapackage in the archive. Instead, you just put "register" *all* the new mediapackages in the episode service, and then you use the service to locate them and pass their id to the workflow service to be processed. > The way I see it, a mediapackage goes into the episode service in the very > moment it enters the system. I understand it as a catalogue of every media > existing in the system (processed or not). After we have our > mediapackage/episode cataloged, we can apply whichever workflow we want, and > obtain different results (such as re-encoding it, publishing it... --just > like we do now). Think about a normal ingestion: you receive the > mediapackage, then you apply a workflow to it. In the new scenario, you > receive the mediapackage, you put it into the episode service AND apply a > workflow subsequently. Should this workflow fail, it is trivial to go to the > episode service, see what went wrong and re-apply the workflow (perhaps > changing some options to make it work this time). > > > No. To clarify: The episode service is intended to be an _archive_ for > media packages processed by the system. It is _not_ for tracking their > processing. That's what the workflow service is for. > I didn't mean that. I'm sorry but I think I mixed backend concepts with UI concepts and that's confusing. I meant that, ideally, I think there should be an "integrated" view of the episode and workflow services. You've got your list of episodes provided by the episode service, and by clicking somewhere, you will see a detailed list of workflows applied to that episode (of course provided by the workflow service). And I'd like to insist: why an archive for mediapackages _processed_ by the system. Why not an archive for _the_ mediapackages _in_ the system? It's a slight difference, but it means a rather deep change in the perspective. Regards Rubén > > > *Christoph said:* > >> *Adam said: 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. > > > If this depended on me, I wouldn't allow for multiple workflows to be > applied simultaneously to the same episode. Workflows are expected to be > fairly complex (they are already, and I expect they will become more complex > as we want to apply more convoluted operations to the videos --cropping, > virtual panning, sound processing--), and thus we have to guarantee the > consistency of data during the whole workflow. I don't think it's a loss at > all: right now, I believe only one workflow can be applied to the same media > package. > > > As long as the system doesn't know anything about what a workflow is > actually doing and as long as media packages are mutable data structures I > agree with that. Having a classification of workflows as Judy proposed may > help for concurrency but this concept needs to be carefully thought out. > > > *Christoph said:* > >> *Adam said: 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? >> 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 > > > I agree with this idea. Episodes can be "idle" (not the best term, I know), > as in "not currently being processed" or they can currently be being applied > a workflow (does this sentence even make sense in English?). This info is > interesting to the user, primarily, because episode cannot be modified until > the workflow has finished (for consistency, as I said before), but also, > because you can see at a glance if some workflow is being applied to a > certain episode, and you can then click to see the details, etc. > > > *Christoph said:* > >> A*dam said: aside from referring to the workflow instance filters, it >> might be helpful to know which workflows were formally run against each >> recording and what their status was (failed, finished, etc) within the >> episode UI. Otherwise users will need to refer to the Finished and Failed >> tab as the source of authority for formally ran workflows when determining >> which workflows to run in the episode context. Not a big deal but a nice to >> have.* > > > > These information will be visible when clicking on a certain episode to get >> the detail view. I will improve the mockup to clarify this more. > > > Not saying that a tab showing all the workflow instances is not useful > anymore, but I believe that being able to see the workflows applied to * > each* episode is better. Both views are complementary, though. > > We could have an "Episodes" tab, and by opening a certain episode details, > we'd see a list of the workflow instances applied to that episode, perhaps > with the possibility of filtering them by state -failed, finished...-. Then > we could have a "Workflow Instances" tab, where we'd see all the instances > together, and we would be able to filter them. So the "Failed", > "Processing", etc filters would be part of the same "Workflow instances" > tab. > > > *Adam said:* > >> *it's unclear why actions are displayed in this context if the list >> represents recordings. I see no harm in a view page per recording, but >> actions should be dependent on the chosen workflow. * > > > Actions should be dependent on the chose *episode:* is it published?; > where?; is a workflow currently being run on it? In other words, they depend > on the current state of the episode. Of course, the current state depends on > the workflows applied in the past, but the important thing is the outcome of > those workflows, the results, and not the workflows themselves. > > *Adam said:* > >> *If edit were available for a recording without choosing a workflow, how >> would changes to its metadata impact associated "running" workflow >> instances? Would edit be turned off in this scenario?* > > > In the way I see it, yes. > > *Adam said:* > >> *Even if no workflow instances were currently running, it seems like the >> edit action should prompt other actions like redistributing the recording. >> Aside from view and edit, I'd think other actions would derive from hold >> states, and would make most sense within the context of the workflow >> instance filters.* > > > The way I see it, the workflow instances should appear listed under the > episode they are applied to. Therefore, one of the states associated with an > Episode (apart from "under processing") could be "On hold". I see an episode > state as "the state of a workflow being applied to that episode, should > there be one". So the user would see a certain episode "on hold", which > means a certain workflow is being applied to the episode and it's waiting > for user action. They would see the episode details and take the appropiate > measures. > > I find also very natural that the users can edit metadata directly, and > then, by clicking "Submit", a workflow instance to update that metadata in > the distributed copies would be launched. This is pretty straightforward if > we could inspect each episode and it's associated metadata. I can imagine a > different set of options specific to certain distribution channels where the > recording is distributed. > > *Christoph said:* > >> The only use case in mind at the time I created the mockup was the "play" >> action. Since this one moves to the details page the column will be dropped >> entirely. > > > This "play" option could be one of those specific options that are tied to > a certain distribution channels. So, we could have an episode distributed to > iTunes and to the Engage part, and we could see a different "Play" option > for each channel, so that we can "play" the iTunes copy OR the Engage copy > independently. > > > Sure, there need to be a "play" action for each distribution channel. > > > *Christoph said:* > >> *Adam said: 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. > > > One of the actions that the user could do (perhaps instead of the "play" > action that is going to dissappear) is "Apply workflow". That will led the > user to a list with all the available workflow definitions, and they could > choose the options needed by clicking on one of them. Them a button "Run!" > will start the workflow on that episode/mediapackage. > > > That's exactly what the mockup proposes. > > > In certain cases, I see normal a workflow can be applied with default > options. For instance, my previous example about ingestion: the ingestion > service receives a mediapackage, puts it in the episode service and runs the > default workflow with the default options. Then, the user can see that > workflow listed in the episode details, and maybe they will have an "Run > again" option which will allow them to set the workflow parameters > previously. > > > *Christoph said:* > >> *Adam said: which date is represented in the date column? upload date? >> creation date?* >> > > > Currently this is the start time, which is the creation date. > > > I think all of them can be interesting: upload date, start time and perhaps > even the date when it was scheduled. We've got records of all that times, > including them in the UI in a visual way shouldn't be overkill. > > > Yes, the columns shown should be discussed. Maybe we can even make it > configurable in a later iteration. > > > *Christoph said:* > >> 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? > > > Yes, I agree that's the status now. > However I do not like so much the "recording"-"workflow instance" > equivalence, because I believe it brings confusion. "Recording" = "Episode" > = "Media Package" sounds more natural to me. > > > My two dollars :P > Rubén > _______________________________________________ > 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] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
