Hi Pawel, > 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.
You are looking at different problems here and it seems they are being conflated, so let's clarify what we are talking about. Workflows: It is correct that every workflow contains a working copy of the media package. Also, the mediapackage contained within the workflow contains a reference to the series document (if applicable). Episodes: I am not sure how an episode contains multiple copies of that Mediapackage. I assume you are talking about the episode service, which is the central place for storing a recording in the latest stage (versions are being worked on as we speak). So an episode *equals* a mediapackage and does not contain one. Again, the episode contains a reference to the series (if applicable). Search service: I assume that by "published index" you are referring to the search service. This service contains copies of the *published* mediapackage as well as a copy of the series metadata so it can return search results based on the mediapackage's metadata as well as the series. Now to your use case: If you want to change the title of a series, a few things need to happen (and actually *do* happen as of 1.3): 1) The title needs to change in the series service 2) The series service needs to send a notification out to other services about that change 3) The other services (search and episode service) need to update their metadata so that searches will return results based on the serie's new title. As indicated above, all this is working in 1.3, so there is no need to retract and republish. Matterhorn is a service oriented application, which implies that there needs to be some kind of communication between these services and also that there may be redundant data, as there should in general be no hidden inter-service contracts based on common data structures. So reading up on service oriented software and OSGi in particular may give you quite a few answers on why some things have been architected in Matterhorn the way they are. > 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. One great way of joining the project is to start contributing by documenting what you found is missing. I am serious about it. There currently is no book called "inside matterhorn", and as long as that's the case, people interested in joining will have to do some learning from code as well as from the wiki. In addition, a lot of those parts that are meant to be customizable *are* fairly well documented. You seem to be looking at changing the underpinnings, which is why there is less documentation available - it's not something that has been a huge requirement so far (I am in no way saying that it would not be a good thing to have). > 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] Not sure what you mean. Are you not introducing bugs when coding on your devices? I do agree that there are new bugs showing up whith new features in Matterhorn, but I would not go as far as putting it in a way that this is the main goal for Matterhorn developers. Also, every time you have been asking on list you got an answer, correct? Does that not count as guidance? I personally have month-old patches sitting on my machine pending review that I provided to you based on your input when you started building the Matterhorn integration of NCast's devices. I would also appreciate if you could go into more details as to what kind of path for the project you are looking for. Matterhorn is an open source project with a number of people and institutions working on it. As a result, there are multiple "paths" that this project is taking. Some institutions are looking into adding semantic features to Matterhorn, while others focus on the learning aspect. Entwine is generally interested in making the software more robust and easier to manage. If you are looking for information on what is being worked on that you don't find in the wiki or on list, you are invited to join the virtual developer meetings and become a participant at the (un)conferences. > 2. > Documenting the project doubles it's value, because --- other people can keep > on developing it. Again: documentation does not just magically appear, and since this is not a product that some company is selling, there is nobody in charge of getting it done. It's everyone, instead, including yourself. Either resources or money have to be thrown at the problem to solve it (aside from people that actually have the required knowledge in the areas of documentation or people willing to dive into the area, learn and document). > 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. Correct. > 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. What you are looking for has most likely been implemented. It is due to a lack of consensus and then resources that part of it has not come to realization, not primarily the lack of knowledge. If you have resources to spend, get involved with the developers and start discussing possibnle approaches. Again, this is not a company with a CEO that is telling their developers what to do. It is a community of shared interest, and consensus needs to be reached in order to implement it. If this is not the way you like it, you are free to take the code and create your own version, that's looking exactly the way you want it. If you want others to help you, you need to invest the time and resources to reach that consensus, then to build it. > 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. Not sure what you mean. Open a ticket, show up at the dev meetings to talk about it if it's of real interest to you, and don't forget to bring resources that can help fix the problem if you *need* it to be solved in a timely manner. > 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... Again, this is up to the community. Since the community keeps changing, that path for the project will inevitably change as well. > 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. Not sure if this is a good way of introducing yourself and the way you would like to work to the community. But this is of course completely up to you... > 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. Detail what you want to achieve in an e-mail to list and include mock-ups if it's design work. Uses cases generally help a lot. Don't forget to include who you think will be doing the actual work and what a possible timeline would be. > (2) > Vote and/or share your thoughts on it. You will certainly get the feedback you are looking for. > (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. Unless we know what you would like to achieve in more detail, it is difficult to tell whether there is work that you can build on. > (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... Again, you will find those people on list. Looking forward to your detailed proposal. Tobias _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
