Hi Greg, I think you've missed the point of my message. There will be independent hardware entities out there not on Matterhorn's X.Y.Z system that will need to communicate with the server. Continually changing and upgrading the firmware on these devices out in the field will be painful and hard to do. Trust me, I've had a lot of experience trying to keep our customers current with our software and it doesn't happen.
Hank On Sat, Sep 10, 2011 at 6:50 PM, Greg Logan <[email protected]> wrote: > On 2011-09-10 5:43 PM, Hank Magnuski wrote: >> One of my engineers was complaining that the Capture Agent API has >> changed yet again in Release 1.2. >> >> It's really critical that the API get locked down and at least be made >> backward compatible. As NCast encoders (and other vendors too) start >> to deploy many units in the field the confusion generated by >> 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
