Agree that we should take an iterative approach, but at some point in the future we might want to consider/research whether this needs to be settable (at an even more generalized level than per workflow) perhaps as a configuration option and/or perhaps leveraging our existing series-based authorization capabilities (i.e. thinking about which users' changes should take priority, e.g. instructors interacting with capture agents, admins interacting with admin UI, etc.).
Judy On Jun 20, 2012, at 9:52 AM, Christopher Brooks wrote: > Tobias, > >> First one would be that at some point, the apture agent may need to >> start talking to the core (e. g to modify the mediapackage that is >> waiting for ingest). >> >> If we don't want that, we'll need to develop a protocol that allows >> the capture agent to, upon ingest, signal how the workflow's >> mediapackage should be merged with the ingested one. A single >> "replace mediapackage" flag as part of the ingest operation may be >> enough to tell the core to skip the workflow's mediapackage and >> merging strategy and use whatever is coming from the capture agent. >> >> Thinking about it more, the second approach seems much easier and >> more solid. > > I think we could just go easier and be explicit at this point that > "agent removed metadata keys" is not supported. So the result of an > agent submitting a mediapackage is always a union. If you wanted > something deleted then you have to do an operation with the server. > > Seems the fastest way to get it done and we can just iterate on it if > need be. > > Chris > -- > Christopher Brooks, BSc, MSc > ARIES Laboratory, University of Saskatchewan > > Web: http://www.cs.usask.ca/~cab938 > Phone: 1.306.966.1442 > Mail: Advanced Research in Intelligent Educational Systems Laboratory > Department of Computer Science > University of Saskatchewan > 176 Thorvaldson Building > 110 Science Place > Saskatoon, SK > S7N 5C9 > _______________________________________________ > 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] _______________________________________________
