Hi, This problems you are describing here are the consequence of how Matterhorn started, and what it has turned out to be. Matterhorn started as a simple "pipeline" with no memory (pretty much like Podcast Producer): "give me your videos and your processing path, and I'll take care of that, give you your resulting feelings and forget about that content forever". Halfway through, though, adopters and developers realized that Matterhorn couldn't be a simple processing tool, but also managing a (big) video repository. That implies not only processing it, but also catalogue and classify all your media content. And manage your collection. Ah, and since we are distributing to third party channels, keeping track of all those "external videos". Ah, and integrate that with my LMS framework. Ah, and we could also expose our data via OAI-PMH. And we could also... The expectations were growing as the project went on, but the initial concept never changed.
The problem is that MH is supposed to be Mediapackage-centric (i.e. the "atom" in the system, the basic container of information), but it turned out to be workflow-centric instead (because a single recording has many different -and redundant- views, depending on whether you ask the search service, the workflow service and the likes). So, I cannot agree more with your concerns. I told it when Tobias proposed the Episode Service: this should be the center of the system, not a simple service on the side, introducing a more realistic view of the media contents, but also more redundance. Yes, I agree the leap to refactor the core of the system is bigger than simply creating an additional service, and perhaps that would have slowed the development of many other features, so I'm not criticizing the approach taken --it was probably the way to go, given the circumstances. However, now we are seeing some inconsistencies, and problems to integrate the different UIs, and I'm sure those are only the symptons of deeper issues at the very core of MH's design. Perhaps your proposal is not coming in the best moment, though, but it states a problem that has to be addressed some time soon. I believe MH has advanced too fast, working in the roof instead reinforcing the foundations so that the house we are building doesn't collapse under it's own weight. However, in a moment when the development work has fallen to a minimum (and I am a part of that problem too), I don't know how we can that such task. Perhaps an agressive repriorization needs to be done, or something like that. I hope nobody takes this the wrong way --I do believe in MH's capabilities and I think what we created so far has a big potential, but there are still gaps that are preventing MH to reach the place where it really belongs. Sorry for the long rant, I guess what I try to say is that I find it difficult to get to do such an ambitious proposal for the time being, though it's something to consider in the long run. Regards Rubén 2012/5/23 Pawel Fic <[email protected]> > > Hi, > > three things: > PROPOSAL. > REASON. > FIRST STEP. > > PROPOSAL: > ================= > I would like to normalize all the content inside Matterhorn. > I would like to make it 2NF or 3NF. > > Of course I am not thinking about having a proposal of SQL database > tables, I am thinking about normalizing the content as if it was a SQL. > For example: > -right now each workflow contains a copy of MediaPackage. > -each episode contains two(!) copies of MediaPackage. > -each workflow and episode contains a copy of serie. > -each published index contains a copy of serie. > > So.. once you change title of a serie, to make it affect a published > episode (published mediapackage -- who knows what is correct!?!) you have > to retract it and re-publish. > > > > > REASONs: > ================= > 1. > Matterhorn is growing fast. There is a bunch of people who know it well, > but those people cannot take care (or can they?) of implementing everything > by themselves? > How do you imagine new developers joining the project, that is not > documented. > > They are working in hurry introducing new bugs, and at some point instead > of guiding, and drawing a path for the project - they will end up being too > busy or just tired. [am I right? I may be terrible wrong here] > > > 2. > Documenting the project doubles it's value, because --- other people can > keep on developing it. > > > 3. > People like me can either spend 6 months investigating every part of the > code, and then start adding something or read about it on wiki pages, and > then try to force some kind of idea, or may learn about the part that they > are interested in in a week. > > I can put up some examples here, but I would not like them to be a part of > this thread. > > > 4. > Saying what will work how, and designing it is usually faster than > implementing it. So: adding episodes tab, and it's functionality can take a > week or two on a paper, get approved --and then jobs can be assigned and > everything will be working fine. > > > 5. > It will enable real C&A. For example: > I have changed a title of an episode, ... but it's still the same in Media > Module. > > Bug or design ? > > Serious bug? > > Minor bug - that will be handled in 6 months, and ruing all existing > installations. > > Now serious C&A is not possible. > > > 6. > I cannot imagine people seriously developing Matterhorn without this kind > of stuff. Auto generated spec is very useful for developers but -- you will > never know if something is missing there, without looking at from a > distance. I am not talking about details (rest parameters), I am talking > about drawing a patch for next 5 or 6 years... > > Once we will figure out what is an episode, what is a workflow, we will be > able to think of distributing stuff to youtube. Otherwise? What do you want > to distribute? > -Mediapackage? > -Episode? > -Workflow? :-) > > Yes. It's working. Something is working. Somebody published something to > youtube. But how many design bugs was introduced. None. Because implemented > code is a design. Once I will change the ways workflows are displayed on a > Recordings page, I will change entire design on Matterhorn, since there is > no design. > > > FIRST STEP. > ====================== > I have to do it myself, propose it to the community. > However I would appreciate help: > > > (1) > Explain me what needs to be gone to have idea of developing this spec > approved. - I can start getting an approval. > > (2) > Vote and/or share your thoughts on it. > > (3) > I do not want to duplicate work. Let me know where to look for parts of it > that already exist, if there are any - but I haven't found none. > > (4) > Help needed - I need people that I will have to consult. > What I want to do it dig into Matterhorn code, > figure out what is > Mediapackage > Episode > etc... > > write it down, send it to few people, > make it official. > > > > Thanks! > > -Pawel > _______________________________________________ > 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] _______________________________________________
