Josh had incorporated a reference impl for event handling in the conductor.
"SeriesUpdatedEventHandler.java responds to series events by re-distributing metadata and security policy files for published mediapackages. "

This concept could be used by the episode service to make sure its data is always aligned. For example, our local Youtube distribution service writes a delivery track to the media package as a way to track distributed media. I would imagine that we would write a EpisodeUpdatedEventHandler.java that listens for Youtube distribution events, and updates the episode's mediapackages based on this event. I guess all services that modify the media package should be registered to this event class so that the episode's media package is always up to date. The only complicating factor is if the service event fails. Would we need to rollback changes?



On 9/15/11 1:21 PM, Christopher Brooks wrote:
Tobias,

Any chance you can devote an extra half hour to the end of the next
tuesday meeting to walk those of us interested through the episode
service?  Thought in particular it might be nice to address:

- diagram data flow in adobe connect whiteboards
- should a workflow operation handler use its local copy of metadata
   from the media package, or a stub that points to the remote episode
   service instead?  The latter would let it update/change/add/remove
   values nice and transparently
- should i add arbitrary metadata to the episode and save it there?
   e.g. if I want someone to be able to see the video that has been
   published on itunes, should I add some metadata about that to the
   episode service so we could link it from uis?

Thoughts welcome on list, I just figure that this service might be
fairly pivotal, as it essentially wraps something we've been using as a
data structure (media package) into an active process.  We are working
on some archival features right now for our local install, and I'd like
to make sure they work well with the episode service (In particular,
the episode service should continue to work without access to the raw
media streams, since I want to move them off to tape after the first
set of processing.  But the metadata needs to persist for future
workflows, which might include emailing instructors a URL, changing
permissions at the end of term, etc.).

Chris
_______________________________________________
Matterhorn mailing list
[email protected]
http://lists.opencastproject.org/mailman/listinfo/matterhorn


To unsubscribe please email
[email protected]
_______________________________________________

Reply via email to