Thanks Tobias. I appreciate your answer. I will read it carefully few more times, and probably I will be asking lots of questions on Matterhorn.
Please, do not get me wrong, I am not complaining... I can write a huge list of Matterhorn pros! You are really doing a great job here. -----As you say: I will think of some example documentation, and put it here, you will be able to say if it's correct or not. We all are probably very busy, I have like three projects I am working on, and Capture Agents is one of them. -----As you say: I attended few dev meetings, however it was a long time ago, so I was just listening. -----As you say: Tobias! Nearest unconference is in Boston! I am hoping to be there. I have just booked a ticked, and a place to stay in Boston (my passport just expired but Ministry of the Interior is just printing the new one, hope that they will make it) I see that Matterhorn project is moving fast forward. I was using Matterhorn 1.3. // I'll upgrade to Matterhorn 1.4. Some examples of a very good job, that amazed me: For example (of a good job). ---------------------------------- 1. in 1.3. there was an annoying ingest bug, I fixed in my copy of MH1.3, and here it is --- solved in MH1.4 2. in 1.3. editions of episodes was missing, now here they are in MH1.4. (I managed to move them to MH1.3) BTW - as far as I noticed you are using DELETE EPISODE / ADD EPISODE --to edit it. If browser will crash, or Internet connection will break --> episode will be lost (I will tell my engineer to check it with MH1.4 and post as a minor issue with of course a patch applied). 3. Lots of new functionality was added. I was amazed how fast. 4. The jQuery code for admin pages was changed! Now it's just better I think. 5. I complained about MH 1.4 not compiling with openjdk-6, added some minor changes to compile it, then once I had some time to investigate those problem it turned out to be compiler's problem (as far as I know, i proposed you a patch), a while ago I have checked the status of a bug --and it was there that it's compiler problem. It's amazing to observe how this project grows. Sorry for pointing out what I do not like about the project, as you say it may be a bad way to introduce myself, I just wanted to point out why documentation is important for on open source project. However, I have noticed that majority of open source project do not have it. I really like Matterhorn, you have done a lot of great work on it, and I am hoping to contribute some code, probably for capture agent.... well as you said: I'll look into it and just develop it, and put it here. Thanks again! --- On Wed, 5/23/12, Tobias Wunden <[email protected]> wrote: > From: Tobias Wunden <[email protected]> > Subject: Re: [Opencast Matterhorn] documenting Matterhorn Entities - how to > start. > To: "Opencast Matterhorn" <[email protected]> > Date: Wednesday, May 23, 2012, 9:30 PM > 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] > _______________________________________________ > _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
