Rüdiger, thanks for brining this to list. The issue has come up over and over again and I feel that it is about time that it be discussed.
When looking at this proposal, I think what we want to do is separate the capture agent into two parts: 1. The capture agent "api" that is talking to the backend system, namely during scheduling, state update and ingest. 2. The capture pipeline For the api part, I think it is strongly needed, so there is a reference implementation that showcases how a capture agent is supposed to communicate with the core and in general behave appropriately. Chris is mentioning in his reply the "soup to nuts" approach that Matterhorn takes on lecture capture. Being more of an architect than a product persion, I would reduce the achievement to the fact that we have been able to develop an api that can apparently be implemented and put to work by multiple vendors, therefore making it easy for institutions to put in place whatever is needed and switch if the chosen solution does not deliver on promised functionality. To summarize, from my point of view it is extremely valuable having that reference implementation in place and keeping it. As for the capture pipeline, I agree with Chris that it is not necessary to support each and every card, operating system or hardware. If the original capture agent is something that people see value in, they will put resources forward. If that's not the case, then I don't think we should be wasting cycles. Tobias On 05.02.2013, at 16:15, Ruediger Rolf <rr...@uni-osnabrueck.de> wrote: > Hi list, > > I started this discussion on the unconference in San Diego last week and I > want to bring this to the Community now. > > I would like to propose that we discontinue the development of the reference > Capture Agent after 1.4. > > We would not delete the current code from the repo or something like this, > bit we will not really maintain the code in the future so that it will be > outdated in the near future, because hardware that we recommend is no longer > available or interfaces and drivers that we use will change. We will need to > create a mockup-capture-agent (a simpler version of the current demo capture > agent) that will prove that our API is still working and can be used for > integration tests. This Mockup-Agent will probably have no 3rd-party > dependencies like the current agents so that it can be installed on any test > server. > > Why should we discontinue the development? > Currently only 2 developers are working part time on the CA. We hardly manage > to catch up on know bugs. We hardly manage to keep the install scrips up to > date with changes that come with new Ubuntu versions. We have not really > improved the functionality of capture agent in the last releases. A good > example for that is that the CA user interface still lacks any usability. On > the other hand we have to compete with other open source implementations of > capture agents and the commercial vendors, which improve their software much > more rapidly. Especially Teltek's Galicaster is an valid alternative to the > reference Capture Agent as it has an open source license too and works on > very similar hardware. Most adopters that currently use the reference CA > could switch to Galicaster. > By switching away from our own implementation we as a community could open up > the discussion with the Capture Agent developers about improvements of the > Ingest-API. With our own CA we would need to write an reference > implementation. Now we would only need to update the Mockup-Agent to test the > interface. > > If we would encounter in the future that we rely too much on commercial > partners with their Capture Agents we could always use our old code again and > update it again. > > I would like to know what the community thinks about this proposal? > > Thanks > Rüdiger > > -- > > ________________________________________________ > Rüdiger Rolf, M.A. > Universität Osnabrück - Zentrum virtUOS > Heger-Tor-Wall 12, 49069 Osnabrück > Telefon: (0541) 969-6511 - Fax: (0541) 969-16511 > E-Mail: rr...@uni-osnabrueck.de > Internet: www.virtuos.uni-osnabrueck.de > > _______________________________________________ > Matterhorn mailing list > Matterhorn@opencastproject.org > http://lists.opencastproject.org/mailman/listinfo/matterhorn > > > To unsubscribe please email > matterhorn-unsubscr...@opencastproject.org > _______________________________________________ _______________________________________________ Matterhorn mailing list Matterhorn@opencastproject.org http://lists.opencastproject.org/mailman/listinfo/matterhorn To unsubscribe please email matterhorn-unsubscr...@opencastproject.org _______________________________________________
