Hi Pawel, I've read through this a couple of times and it keeps sounding to me like I'm coming off hostile. Rest assured that this is not an attack against you, merely a spirited defense of the current configuration :)
On 4/17/2012 6:20 AM, Pawel Fic wrote: > That is my point. It's disabled, but present. > Install MH 1.4 (from trunk) and notice that "demo_capture_agent" entry is > still there, even w/o "matterhorn-capture-impl.jar". Please ensure you don't have the capture bundle built, clear your database, and attempt to reproduce this. As far as I know the demo CA is not (and should not be!) created by default, which makes me think you're either not clearing your DB or it's running somewhere. > > To sum up my point, there are following design problems: > > 1. > demo capture agent already become a part of server, and it everywhere. in the > server's code and server's configuration. Skipping -Pcapture does not solves > this problem. In the config files yes, but not in the code. Please point to the parts of the CA's code that are deployed by default in 1.3 or newer that. > 2. > newcomers looking at Matterhorn try to change server's configuration trying > to make it work with their capture agent, or trying to figure out what > "demo_capture_agent" is. This is an issue, for sure. Something that we can't necessarily ever solve. If we remove the CA config files new users will just run without them and complain when things don't work. This is a large and complex project, and new adopters need to be willing to read the documentation (which is actually there now!). > 3. > Sometimes people are forced to use demo capture agent. > Using one that is actually part of a server is badger-legged solution. Forced to use it for what? Testing their new installs when they don't have a real CA? Isn't that what it's for? I'm not sure what the objection is here... > Solutions 1: > Fixing current solution, by splitting configuration into server and demo > capture agent's & separating the code. + explaining how to install server > only & how to install demo capture agent only. > > > CONS: > -developers will soon again mix capture agent and server code (unwittingly). > > -developers will introduce changes to server and reference capture agent at > the same time (common part of code) - and alter the protocol for > communication between the server and actual capture agents. We have detailed instructions for how to install standalone CAs and cores: http://opencast.jira.com/wiki/display/MHDOC/Install+Capture+Agent+v1.3 http://opencast.jira.com/wiki/display/MHDOC/Install+Source+Linux+v1.3 Splitting things up increases testing and build complexity massively, while at the same time not giving us much in the way of return. Yes, we would have fewer config files in Felix by default, but that's not (imho) much of a gain. > > > Solution 2: > removing demo capture agent's code > > CONS: > -no comfortable, easy in use & install reference capture agent. Right, exactly. A new adopter who has no funding or desire to build/buy a CA going to test is just going to walk away if we do this. > > Solution 3: > moving demo capture agent's code into separate repository. > > > PROS: > 1. nobody will confuse demo capture agent (part of the server), with the > server. I'm not sure I follow here. By this logic you could confuse part of an engage node with part of the admin node. Perhaps we should split each profile up into its own repo? > 2. developers will have a reference demo capture agent (nothing but java > needed). This is already the case. The CA's impl bundle *is* the demo capture agent, and the reference agent that runs on real hardware as well. As of 1.4 it no longer needs jv4linfo when running as the demo capture agent either, so it really is Java only now. > 3. there will be an option to find problems like - not updating Capture > Agent's URL properly or easily test capture on multiple agents. If this type of thing has become an issue then we need to file tickets and write new integration tests, not rip things apart so that it becomes harder to test. > 4. there will be an option to differentiate reference capture agents > (different capabilities) for testing and test server with multiple capture > agents even working with one PC. This sounds to me like a documentation issue, or a user issue. The whole point of the wording around the demo CA is to make it clear that it's a demo (MOCK_INPUT_DEVICE, demo_capture_agent). > 5. Capture Agent Developers will have a place to start. They do. In the capture-impl bundle. Or do you mean that the lack of documentation on how the reference CA works internally is a difficult hurdle to overcome as a new developer? > 6. Server developers may be told to test their code with previous version of > reference Capture Agent. They can already do this. There's nothing preventing you from deploying multiple CAs to the same machine in demo mode. > > CONS: > 1. third repository project (next to server, actual capture solution). Plus extra testing and management requirements. Keep in mind that these are things that we are already desperately short on. G > > =============== > OK, fixing what we have right now is also a solution (the first mentioned), > but I think not the best. > > > -Pawel > > > --- On Tue, 4/17/12, Tobias Wunden <[email protected]> wrote: > >> From: Tobias Wunden <[email protected]> >> Subject: Re: [Opencast Matterhorn] Separate Capture Agent & Matterhorn Server >> To: "Opencast Matterhorn" <[email protected]> >> Date: Tuesday, April 17, 2012, 12:21 PM >> Rüdiger, >> >>> I would be a +1 for removing the demo capture agent. I >> thought it would not be part of the default 1.3 install >> anymore? >> >> the demo capture agent is only built if you include >> -Pcapture in the commandline. >> >>> It would be a good idea too to separate the CA release >> cycle from the core release cycles. It would probably help >> to get the APIs more stable. And the CA has other milestones >> like th release of a new Ubuntu version, that the Core >> system. Unfortunately this would probably mean that we would >> need a release managment for the CA too and we would need a >> QA phase for this. Another pro would be that testing the CA >> and the core can be more focused than, as we don not need to >> evaluate the whole system. >> >> I agree. >> >> 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] > _______________________________________________ > _______________________________________________ Matterhorn mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email [email protected] _______________________________________________
