Hi all, This comes from a recent question at the list about how to migrate from 1.1 to 1.2 . AFAIK, there are not 'standard', even tested or stable way to do so, and I cannot believe that a system that considers himself in a version 1.2 is not offering a safe upgrade procedure, something which is may be tolerable for an alpha version, even a beta version, but not in a fully working system as we are trying to see Matterhorn. This is not a complaint to anybody in particular, I'm well aware of why there is not a solution to this problem, as there's not for other issues in Matterhorn --there is not enough hands to do the work. And I really think we've been doing great so far, but I can't avoid thinking that, in this specific issue (the workflow migration), there may be something else.
I strongly believe that those migration problems are perhaps caused by a too-twisted treatment of the recordings and the workflows in matterhorn. In the current philosophy, "workflow" is just a certain way of seeing a mediapackage, while the search results are another way of seeing it. Even if it *is* the same mediapackage, its contents are distributed along different folders --not necessarily bad-- and indexed in different indexes --but there's no central index that relates all the files of a mediapackage--, so that you just cannot get a complete picture of the mediapackage altogether. I strongly believe that we should see the mediapackage as a list of related files including media, metadata and attachments TO WHICH you can apply different workflows, then you got a simple way of processing everything, simply because: 1) When you see two different workflows, it is unclear (at a glance) that they have been applied to the same files or not. Instead, you may have your list of different mediapackages at the system, to which you can apply different workflows, thus modifying the number, type, flavor, metadata, etc. of the files in the mediapackage. 2) Everything is centralized: the mediapackage flavors can tell you which files were the originally ingested (*/source), which them were used in the processing --if not erased afterwards-- (*/work), or which of them are distributed (*/distribution --I think). Now you've got a set of scattered files that are related in some ellusive way, which you can guess by inspecting .xml list from a couple or three services. If the bondage between the source files and the distributed files were more explicit, there would be no need to ask several services to get the complete picture. I know this idea is not very well developed, but I strongly believe it's the cause of much of the matterhorn problems --we are taking the wrong approach. Then again, this is such a big change and I don't know if it can (or even should) be undertaken, nor if other fellow developers agree --partially, at least-- with this vision. I don't dare to make this a #proposal, because perhaps I'm just seeing a part of the problem and there may be good reasons to do so, but I can hardly imagine them. I hope this is not offending anyone with this message. I did not took part in the designing process and I don't want to question the criteria followed then, but I think that we may have took a wrong turn somewhere, and perhaps it's better to think about it now before going any further. Just want to open a constructive debate here, and if I'm wrong (which I am more often than I would like), I will gladly take my words back. Thanks, Rubén
_______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
