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] >> _______________________________________________ > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
