Tobias, > the episode service is turning into a front end for the archive. we > did not have the time and resources to get everything done at once, > therefore the iterative approach of first creating a central place to > store mediapackages (without their elements) and only now implement > the actual archival functionality with support for persisting the > full mediapackages, versioning, asynchronous access etc.
Sure, this sounds good. > yes. the working file repository will still be the working storage > during processing, but in theory, a workflow's *temporary* processing > artifacts should be gone from it once it has finished. Great, I figured this is how the service was always meant to be anyways, and it's how we treat it here (fast storage but not lots of it). > > Nothing would break with this model? Or are the > > workflows that the capture agent wants to start run from the episode > > service? E.g. would I go capture -> put in episode -> run workflow > > -> remove from episode? (in order to keep my own processing flow) > > I don't see why the capture agent would want to do that. Workflows > that involve the capture agent either originate from the scheduling > service or from ingest directly, and there is no need to involve the > episode service. Perfect. > That's ok, just start sending your thoughts to list and make sure > Christoph is aware of them, as he is currently working on > implementing a first version. In addition, the actual archival will > be a replacable piece, which means you will be able to put your own > implementation in place if you don't like the way the (for now) > default implementation does it. I'd prefer to use the stuff you make, but if there is a way I can make it "tape friendly" by providing input early I would hope that would be possible. For instance, we tend to keep things oganized by date/series. So something like: 2011/series name/episodeid/... Makes it easy to grep through a log of what is on the tape and find what we want to retrieve. If it's more like: 2011/uuid/uuid/... That is decidedly ungrepable :) If uniqueness needs to be considered (e.g. do people reuse series names?), then I would prefer that multiple values be considered, like: 2001/seriesname-uuid/episodeid-uuid/... We get into path length issues, but including the first 12 characters of each series or episode id would be something at least. > > Also, I don't see on the link how I important a media package (from > > a new capture agent, or from another university, etc. etc.) into the > > episode/archive service. I would like to do this and this might > > let me relax the requirement on the directory structure (since I > > could just archive our stuff to tape the way we already are, then > > import it again into the episode service to run more operations). > > Currently, I am not aware of any requirements in that direction. > Importing of a mediapackage from other systems or capture agents is > done in an easy way by configuring an inbox where you just drop the > mediapackages and configure a workflow that sticks them into the > archive or does some other processing (or both). However, importing > through the archive does make sense from my point of view. Could I put it in the inbox with a workflow that just adds it to the episode service? E.g. if I distributed this to youtube already, but not to itunes, and I wanted to push it to itunes as well as do some metadata editing or something, it would be handy to put it in the inbox and have it just show up in the episode service where I could do multiple transformations on the media package. If this was something that could be done, I could see us changing the default workflow for the inbox to say "put in episode service", and then we do all of our "work" from that screen. 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] _______________________________________________
