>
> Ok, this means that workflow ids MUST NOT have spaces in
> them, or they
> won't work here. An important side effect of this
> method of
> implementation.
>
> (So the workflow with id "unconference streams" wouldn't
> work).
>
> Otherwise this looks fine to me, I'd be +0 since I support
> it but can't
> add development towards it,
>
No! This feature will not affect workflow ID's at all.
My dummy workaround works on workflow id's and I will not go with this lame
solution.
Stop stop stop :-)
No! workflow ids will not change.
Now on my installation I use workflow ids.
Sorry, I work in such a hurry recently (Mattern, Encoders, Windows Driver
issues) :D we are trying to hire some people....
Let me describe it on an example:
1.
There is an existing workflow definition in "retract.xml" and another one in
"unconference_streams.xml" OK?
2.
When you go into the XML code of the workflow definitions, right now they look
like this:
<<<<<<<<<< retract.xml:
<definition>
<id>retract</id>
<description>Retract media package</description>
<operations>
(...) some <operation/> nodes (...)
<operations>
</definition>
<<<<<<<<<<<<<<<<<<<<
<<<<<<<<<< unconference_streams.xml:
<definition>
<id>unconference streams</id>
<description>Retract media package</description>
<operations>
(...) some <operation/> nodes (...)
<operations>
</definition>
<<<<<<<<<<<<<<<<<<<<
And all components retrieve those workflows by simple endpoint:
/workflows/definitions.xml
or:
/workflows/definitions.json
//////////////////////////////////////
My proposal is to extend Workflow Definiton with OPTIONAL node: <tags>
and add OPTIONAL field "tags" to the endpoint....
So there would be following calls to the endpoint:
equivalent result (all default workflows)
/workflows/definitions.xml
/workflows/definitions.xml?tags=default
customized request (only workflows for episode service)
/workflows/definitions.xml?tags=episode
And the workflows would look like:
<<<<<<<<<< retract.xml: -- we do not want it on default list, extend it with
tag "episode"
<definition>
<id>retract</id>
<description>Retract media package</description>
<tags>episode</tags>
<operations>
(...) some <operation/> nodes (...)
<operations>
</definition>
<<<<<<<<<<<<<<<<<<<<
And the unconference_streams.xml?
We want it to stay the same.
<<<<<<<<<< unconference_streams.xml:
<definition>
<id>unconference streams</id>
<description>Retract media package</description>
<operations>
(...) some <operation/> nodes (...)
<operations>
</definition>
<<<<<<<<<<<<<<<<<<<<
And now the result:
retract.xml and "retract" workflow was extended with new feature - on new
Instances it will not be listed in default calls - capture agents will have a
change to use it, and it will be gone from upload and scheduler.
On old instances- even if somebody will add workflow with "<tags>...</tags>"
then, node will be ignored and it will work just as old version.
And on new instance of the server - in espidoes tab we will have to request for:
workflows/definitions.xml?tags=episode
Is this example clear?
=============================
In future, we could equip workflows with roles like:
<definition>
<id>retract</id>
<description>Retract media package</description>
<tags>episode,role:ROLE_ADMIN</tags>
<operations>
(...) some <operation/> nodes (...)
<operations>
</definition>
<<<<<<<<<<<<<<<<<<<<
And - role admin will be required to apply this workflow and/or retrieve it as
the results of:
/workflows/definitions.xml
Chris,
I am experienced software engineers and software architect :-)
Sorry about beeing not quite precise -I hope it will clear all your doubts.
And one more think:
+1 - means I vote for this feature
+0 - means ?
Sorry I am asking you, there is a change I can find it on a Wiki, but really
really, those I have deadline with two project on the end of June and the
unconference was two weeks of a delay on everything...
ps
----
And yes, I think there should be some permissions on who can apply what
workflows to what episodes.... Also our encoder is obtaining list of workflows,
and I wanted him to receive only those that are valid - tried to implement user
access to workflow definition (we got it), but ... Capture Agent is identified
with ROLE_ADMIN...
Why there is no ROLE_CAPTURE_AGENT reserved for capture agents.
I can understand that there can be some in customized distributions :-)
Capture agents are identified by authentication method - it's fine. But
ROLE_CAPTURE_AGENT will be one of the proposals I will submit somewhere in the
future :-)
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn
To unsubscribe please email
[email protected]
_______________________________________________
