On 11-09-12 08:07 AM, Rubén Pérez wrote: > Hi everyone, > > I cannot agree more with Hank. If I may add something more to the > discussion, the CA APIs are not RESTful at all, while some other APIs > changed their URLs months ago to comply with the standard as much as > possible.
Make up your mind, you either get stable APIs or RESTful endpoints at this point! We chose to keep the REST endpoints as stable as possible, but that means we're stuck with non-RESTful endpoints :) > Another problem is that, while the "-api" java class has but a few > endpoints, the "-impl" class incorporates many more that are BASIC for > the CA's functioning but are not even reflected in the API. I strongly > believe this is a serious situation that must be addressed asap, because > it has been like this since I can remember, and we can see the results: > the CA is (arguably) the most problematic, bug-prone piece of the > Matterhorn software. My opinion is that these API issues are the > reflection of some structural and design problems that should have been > addressed at earlier stages of the development, but unfortunately it was > not done. I think you're mixing up the code API with the REST api. The code API is a little messy as you remember, but the REST api lives entirely within the impl bundles. The docs for these endpoints are (mostly) up to date unless someone's changed them since I last looked. > If this debate leads to concrete #proposals to improve, fix, or whatever > task needed to make the CA better, I'm certainly willing to work on that > and help those demands come true. I definitely agree that we need to be more clear in terms of which endpoints have been changed, but I don't see how to do this. If we put it on the committer then what happens if they forget? Should the RM do a diff at release time and figure out the changes then? G > Best regards > Rubén > > 2011/9/12 Pawel Fic <[email protected] <mailto:[email protected]>> > > 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] > <mailto:[email protected]> > > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > <mailto:[email protected]> > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users > > > > > _______________________________________________ > Matterhorn-users mailing list > [email protected] > http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
