As a member of the community, I am against overwriting data in the server, by those delivered by capture agent. Data delivered by the agent should be a clue of what it supposed to be.
I also do not like the idea, that Capture Agent is picking a workflow definition to be applied to the video. Especially in a case of a scheduler, when it is all identified by wokflow instance id. However instead of changing the code, I would go with the following approach: 1. identify minimal mediapackage for Matterhorn required so far. 2. figure out what minimal mediapackage we will need in a future. 3. let CA developers contribue some code to the project, by reducing the MediaPackage requirements. Well: I am the one complaining on the lack of documentation, so let me be the one who will propose the minimal mediapackage, and a set of clues what mediapackage is, and what it must contain, and what it may contain right now. I can commit on uploading this spec here (as a txt or html document), and then when it will be ready we will be able to put it into wiki. I am looking forward for some more comments, I like the one from Greg, that "createMediaPackage" is not needed. Well... if you are using zip ingest - the endpoint is assigning new id to the mediapackage. I find it perfect. I am pretty sure, that we could remove "createMediaPackage" endpoint, and some other endpoints - having only two ingest endpoints (one zipped, and one from the content of mediapackage)... Of course! It will be there, for backward capability :-) --I will do this .. I would love to say by the end of this week, but if I will not make it - I will do that on Saturday. Is that all right? Best Regards -Pawel --- On Tue, 6/19/12, Greg Logan <[email protected]> wrote: > From: Greg Logan <[email protected]> > Subject: Re: [Opencast Matterhorn] Capture agent catalog ingesting #proposal > To: [email protected] > Date: Tuesday, June 19, 2012, 8:21 PM > On 6/19/2012 7:59 AM, Tobias Wunden > wrote: > > In the early stages of Matterhorn, the approach to > ingesting a mediapackge used to be that everything that is > part of the mediapackage will be sent to the capture agent > through the iCalendar feed and the capture agent would > compile the full mediapackage and ingest it. Next to the > recorded media files, this namely includes the dublin core > catalogs for episode and series. > > > > With 1.3, this approach has changed to a different > model. The reasoning behind the change was that we wanted to > put as little of a burden on the capture agent > implementations as possible. What happens now is that at > scheduling time, a workflow is created, containing all of > the catalogs. The workflow is sitting there waiting for the > capture agent to ingest. Once the ingest happens, the > mediapackages (the one that is part of the waiting workflow > and the one ingested by the capture agent) are merged. > > > > Unfortunately, an implementation error resulted in the > series dublin core not being added to that waiting > mediapackage (while the series id is still being set), so if > the capture agent did not add this series catalog to the > mediapackage, it would not be part of it. Up until now, this > went by unnoticed, since the series logic is solely based on > the mediapackage metadata, which did include the series id. > Only if one was interested in other series metadata itmes > would one need to get hold of the catalog itself. > > > > As a conclusion, I am suggesting the following change > of behaviour starting with 1.5, and would like to get > feedback from capture agent manufacturers: > > > > In the case where a recording is scheduled, the > workflow should contain all metadata as catalogs (this means > fixing the current implementation by adding a reference to > the series catalog). Once ingest happens, the mediapackages > are merged in such a way that items that exist in both the > workflow mediapackage and the ingested mediapackage will be > taken from the ingested mediapackage. Equality of > mediapackage elements will be determined by element flavor. > > This, to me, brings up three questions. > > 1) As an implementer, I still use the > /ingest/createMediaPackage > endpoint to create the mediapackage when ingesting, > correct? Or is the > text of the source mediapackage going to be embedded into > the event somehow? > > 2) As we discussed in the meeting this morning, what > happens if I > ingest an updated catalog? Whose takes > preference? I would assume the > CA's, but this should be made clear. Do we have a CA > ingest contract > somewhere? I have the CA communication protocol wiki > entry, but I'm not > sure this falls under it... > > 3) Is the catalog going to continue to be attached to > the ical event? > If it is not longer being attached the implementers don't > really need to > change their code (as long as they aren't *depending* on > that file being > present). If it does continue to be attached then > implementers need to > have a way to determine if the file has been changed locally > (assuming > they have an interface to change it). > > > As a consequence, implementors (including Opencast > itself for the reference platform) do *not* need to and also > should not send catalogs as long as they are not looking to > overwrite what's on the server. Also note that this > implementation allows for series or episode metadata to be > changed on the capture device. > > It's not going to hurt if they ingest the catalog anyway, as > long as the > content is the same, correct? > > I'm +0 for this. What we have now seems to work, > despite it not being > technically correct. I'm also fine with changing it, > so if someone > wants to do the work on the MH core side then I have no > problem merging > the patches. > > G > > > The corresponding ticket has been created as > > http://opencast.jira.com/browse/MH-8906. > > > > Tobias > > _______________________________________________ > > Matterhorn mailing list > > [email protected] > > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > > > > To unsubscribe please email > > [email protected] > > _______________________________________________ > > > > > > -----Inline Attachment Follows----- > > _______________________________________________ > 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] _______________________________________________
