Hi Chris, 

First of all, to be precise:
"Filtering list of Workflow Definitions" (sorry about that), 
but you all got it right.



> But I don't know
> much about the episode service.

The episode service allows you to apply a workflow to already uploaded 
recordings - like: "retract from distribution services", or you can create a 
workflow that re-converts the video to different profile (lower bandwidth 
etc.). 

BTW (off topic):
Talking to people, how they use MH is very interesting, and it is a different 
topic, but: haven't you thought about performing operations on already ingested 
Media Package?
I can understand it's just publish & forget, but - how about retracting if 
something needs to be altered, or licensed? 
Trimming recording after publishing? 
How it is currently solved on installation that do not use the Episode Service 
- I know it is a topic for different discussion, but I sure would like to learn 
how it is handled in real life scenarios, existing installations.




> Some comments:
> 1. Do you think it is necessary?  Do you think people
> will have lots
> of workflows?  We only have a couple at the
> moment. 


Well, in Matterhorn's default installation there is retract workflow, so it 
will be useful to fix MH-8780 from 25/Apr/12 as Judy pointed this out. 
I haven't spotted this bug... 
Our Q&A wanted to fill in bug report, but I told them we need it as a feature 
because people (well Q&A here in my office) are instantly scheduling sessions 
with "retract" workflow :-)

Other than this, we have come up with some workflows like: 
 "Delete episode from the hard drive", 
 "Fix the episode", 
 "Split episode into presenter & presentation", 
 "Combine into one stream" - reverse to the previous one.

Well, and they all appear there on upload page. 

Other than this, I imagine that in future, there will be workflows that can be 
applied to one kind of media, wokflows that can be applied by administrator 
only (like fix something, add watermark) or workflows that can be applied by 
the video owner (like: "retract for review").

So those are two reasons for this feature:
 (1) it solves 8780 
 (2) it allows to filter workflow definitions for different accounts like:
       -scheduler  
         (I imagine a workflow: send email 24 hours before the event, 
          that can be applied only to scheduled event, not uploaded)
       -uploader
       -episode service

And for future use, I imagine every recording owner (the admin, the professor) 
would have a list of workflow definitions that could be applied to the video - 
like "convert it to low res" (for AV technician), or "retract it for me to 
trim" (for a professor that recorded on a video how somebody talks to him about 
his private issues).

AV technician would like to apply his own set workflows to uploaded episodes 
(available after he will log in).
The professor would not like to have "convert it to different res" on his list 
of workflows. 
It will be handled by user role, but still a filtering mechanism will be needed.

Does it sounds like a useful feature?
Simple, not complicated nothing fancy - just useful. :-)




> 2. <tags> should not be a mandatory tag, and default
> should be implied
> instead of required

Of course! It's all optional. If there are <tags> - then they can be used, if  
you will ignore it - then it's just as it is right now. 
Nothing changes (backward culpability). Nothing at all,  you can just ignore 
those two.


> 3. What is the data type of <tags>?  Is it
> NMTOKEN?  (A space separated
> list of values?)  Or multiple <tag>
> children?  I would like to see how
> the tags "pre-conference" and "unconference streams" would
> be handled
> by the back end.

NMTOKEN. 
First of all, those tags will not be visible to end user, so there will be no 
special characters. I do not see a need for multiple <tag> children.



> 
> I'm not against the proposal, but wouldn't mind seeing it
> flushed out a
> bit more.  Thanks for bringing these thoughts to list,
> 

I understand. I will have a detailed description soon.
Especially that it is fix to bug report from April.


> Chris
> 

Thanks a lot for a comment.


_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to