Hi Rüdiger, I agree that it would be a good idea to have the mediapackage on the filesystem. The good news from my point of view is that the archive will allow us to do just that. It will write the mediapackage and everything else that is selected for archival to disk.
Another option would be to write a workflow operation handler that writes the mediapackage XML to a directory or posts it to a backup utility. Tobias On 04.10.2012, at 10:25, Ruediger Rolf <[email protected]> wrote: > Hi Greg, Hi Tobias, > > in a way I would really appreaciate it to have the mediapackage in the > filesystem, especially when it comes to backup or exporting the data, but I > see the concerns that it will have heavy impact on the overall design of the > system. > But wouldn't it be an option to dublicate the mediapackage in the filesystem > currently as a first start to this issue? The mediapackage methods could > simply write the new mediapackage to the WFR whenever the MP got updated. In > later versions of Matterhorn we could than easier add methods to import the > MP or change the whole MP-processing. > > Regards > Rüdiger > > Am 03.10.2012 17:51, schrieb Tobias Wunden: >> Hi Greg, >> >> as discussed during the meeting, it may or may not be a good idea to move >> the mediapackage xml out of the database. The idea of it being in there is >> that the mediapackage is an argument to the 'start workflow' operation, and >> the service registry and its job dispatching facility stores the arguments >> for service calls in the database so there can be failover. >> If we now move the mediapackage out of the db onto the filesystem and >> replace the db entry with a file:// or http:// url instead, job dispatching >> can be completely broken by cleaning up the working file repository or >> random places on disk. >> >> From my point of view, this suggest investigating whether there is a >> datatype that is better suited such as a BLOB or anything similar, since >> Matterhorn only uses the field for later reference, not for querying, >> searching or the like. >> >> Tobias >> >> On 29.09.2012, at 00:02, Greg Logan <[email protected]> wrote: >> >>> Hi folks, >>> >>> I have a question for those familiar with the job architecture: Why do >>> we store the mediapackage xml in the jobs table? Why not a link to the >>> file in the filesystem? I have multiple captures here which overflow >>> the payload column during distribution. Everything else works, just >>> this particular piece of media appears to have a lot of scenes. I am >>> uncomfortable changing the segmentation settings since they obviously >>> work fine as is. I'm processing this lecture instead as a >>> presenter/source to avoid the scene detection, but this is an extremely >>> wasteful workaround. >>> >>> I'm tempted to propose that we should move that file onto disk where it >>> belongs in 1.5, but I'm not familiar enough with the jobs architecture >>> to say for sure. Could those who are more familiar with it (Tobias? :)) >>> chime in and give me a hint of how much work is going to be involved here? >>> >>> Thanks, >>> >>> G >>> >>> _______________________________________________ >>> 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] >> _______________________________________________ > > > -- > > ________________________________________________ > Rüdiger Rolf, M.A. > Universität Osnabrück - Zentrum virtUOS > Heger-Tor-Wall 12, 49069 Osnabrück > Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 > E-Mail: [email protected] > Internet: www.virtuos.uni-osnabrueck.de > > _______________________________________________ > 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] _______________________________________________
