How about.... Creating a web page called "Matterhorn REST Enpoints". That will contain a detailed description of the API.
Then figure out who is responsible for the project Matterhorn, and who decides if the API change is necessary - and this person would have to approve the changes to the spec. The difference between what the spec says and what the code does is bogus behavior of the code. A great start would be do document existing rest endpoints. For example I will have hundreds of "simple" questions like: what /capture-admin/recordings returns ? Other than a list of entires called "recordings" (what are recordings) that recently changed it's state. Usually: "<ns1:recording-state-updates/>" It is not important if API changed between Matterhorn 1.1, Matterhorn 1.2 or Matterhorn 2.0, 2.0.1 or 2.0.1b. I want to be sure that this change to API was necessary, and also: what the API calls do. Without this it will be really hard for third party engineers / companies / students to develop their capture agents/schedulers/confidence monitoring and integrate with Matterhorn. -Pawel > >> mismatched API's can become a serious headache. > > > > I can't find any documentation relating > (Adam/whomever: Perhaps this > > should be doc'd somewhere?) to this, but previous > discussion on list > > developed the following rules: > > > > Versioning system: X.Y.Z > > > > Within Z releases the API does not change. These > releases are bug fixes > > and security updates > > > > Within Y releases the API *may* change. These > releases can add, change > > or remove features, as well as introduce new bugs and > security holes ;) > > > > If you're dealing with a different X release then all > bets are off. We > > will probably rewritten everything in Python by that > point. > > > > In all seriousness, I know of at least two changes. > One was a CA state > > endpoint, and that was to fix a bug. The other is > the schedule download > > endpoint, and that was for a feature I believe. > > > > G > > > >> The capture agent world is no longer restricted to > the home-grown > >> do-it-yourself models, and the MH development > community needs to > >> recognize this. > >> > >> Hank > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > _______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
