Tobias, I think I'm beginning to understand:
> 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. So the episode service is still a work in progress, and rather incomplete without the archiving facility behind. That explains many of my doubts. Also, the fact that the "official" definition of the service reads: The Episode Service *will* offer a persistent storage for media packages – > aka episodes – and its content, i.e. tracks, metadata, etc. This will be > called the archive. , doesn't help either. When I read that, I assumed that since the Episode service is already in place, it *already *offers a persistent storage, etc., the "will" being a manner of speaking. I'd say, also, that the definition is inexact, since such persistent storage is not provided by the Episode Service, but by the Archive Service, of which the Episode Service is but a front end + the logic to start workflows on that archived media. I agree with Tobias that the archiving systems should be transparent to Matterhorn, or, in other words, that MH shouldn't have to worry about the physical storage of the resources. That's a lower level concern IMHO, that indeed must be take into account, but that is one level below Matterhorn's realm. Regards Rubén 2012/6/20 Christopher Brooks <[email protected]> > 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] > _______________________________________________ >
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
