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] > _______________________________________________ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
