Hi Greg, >> 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?
You are free to use this strategy as well as using the addZippedMedipacckage method. There should be no difference in behavior. > 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... As I proposed, if a capture agent should decide to ingest a catalog, it should take precedence over what is on the server. The reason to allow this is to enable capture devices to present metadata editing capabilities to the instructor. > 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). That's a good question. I don't see a reason why this should be changed, it may still be good for the capture agent to get hold of all the metdata, so it can be displayed on control screens and metadata editing uis. >> 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? Correct, but how would you know? If the data is updated on the server, the iCalendar feed will be updated as well, however it depends on your capture agent's polling interval to make sure you have the latests. This is why I am proposing to - by default - not add the catalogs, so that the one from the server is taken. > 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. Christoph will add a patch for adding the catalog to the server version, which fixes the problem for those capture agents that are already *not* adding the catalogs. Tobias _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
