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]
_______________________________________________
