For one thing, it's a potential fix for a 1.4 usability bug: http://opencast.jira.com/browse/MH-8780 (which is written very specifically about "Retract Media Package", but should really be about any workflows that aren't relevant in certain contexts).
Judy On Jun 20, 2012, at 10:11 AM, Greg Logan wrote: > Further to Chris' comments, I'm not sure I entirely understand what the > point of these changes would be. Is this to be able to find workflows > faster? To be able to filter them when the UI tries to show a list to > the user? > > I don't have a problem with this as long as you can provision your own > development resources. I'm just not sure I understand what everyone > gets out of this if you create this patch :) > > G > > On 12-06-20 10:39 AM, Christopher Brooks wrote: >> Pawel, >> >> 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. But I don't know >> much about the episode service. >> 2. <tags> should not be a mandatory tag, and default should be implied >> instead of required >> 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. >> >> I'm not against the proposal, but wouldn't mind seeing it flushed out a >> bit more. Thanks for bringing these thoughts to list, >> >> Chris >> >> On Wed, 20 Jun 2012 05:14:39 -0700 >> Pawel Fic <[email protected]> wrote: >> >>> Hi, next step in joining the community :-). >>> Instead of just filling in a bug report, here is a proposal: >>> =============================== >>> >>> >>> Right now, when episode service is available, there will be probably >>> more workflows in the system, that are operating on existing episodes >>> already ingested into the system. >>> >>> The example of such a workflow is "Retract media package". >>> When we go to upload page, we can upload new recording and apply >>> "retract media package" to it. >>> >>> So, my proposal is to add a way to filter workflow definitions. >>> >>> My current workaround is: >>> ============================ >>> With my installation of Matterhorn, I just changed ids of workflow >>> definitions to start with appropriate prefix: "new-" or with >>> "existing-" etc. It works great, but this is lame solution. >>> >>> >>> The proposal: >>> ================== >>> The actual proposal is then to add OPTIONAL field: "tags" to the >>> endpoint: /workflow/definitions.{output:.*} >>> >>> and then inside workflow definition XML place optional element: >>> <tags></tags> >>> >>> >>> So in case field "tag" contains "episodes" only workflows with >>> <tags>episodes</tags> are listed. >>> >>> >>> So.... >>> >>> inside "Retract media package" workflow we would add: >>> >>> <definition> >>> <id>retract2</id> >>> <title>Retract media package</title> >>> <tags>episode</tags> >>> <description>Retract a media package from all distribution channels. >>> (...) >>> </definition> >>> >>> >>> and to retrieve it we would have to use: >>> >>> /workflow/definitions.xml?tags=episode >>> >>> >>> BACKWARD COMPATIBILITY: >>> >>> On the other hand, all other workflows withouth <tags> field, would >>> be inserted as: <tags>default</tags> (currently such field would be >>> ignored). >>> >>> >>> Then... assuming field tags in /workflow/definitions.xml is empty or >>> not set - it would be defaulted to "default". >>> >>> /workflow/definitions.xml?tags=default >>> >>> >>> >>> What do you think about this kind of enhancement? >>> >>> >>> I can assign resources to implement it if it will be approved. >>> Also workflows are stored in Solr Index, so somebody who know >>> Matterhorn could propose a better solution or let me know what may be >>> the consequences of adding field: <tags> to WorkflowDefinition. >>> >>> >>> Would you find this feature useful? >>> >>> >>> >>> Best Regards >>> -Pawel >>> >>> >>> ps >>> >>> On the other hand - we can right now only distinguish two or thee >>> kinds of workflows (hidden-, new-, existing- ) >>> >>> So we could assume that workflows with id starting from "hidden-" are >>> hidden, starting with "existing-" would operate on already ingested >>> mediapackages, and all other can be applied only to new recordings. >>> >>> >>> _______________________________________________ >>> 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] _______________________________________________
