I like to sit on the sideline and critique the work that other people did. I tend not to participate in committees as I find them totally counterproductive.
To make a protocol a success, I think it should be simple. Now, simplicity is in the eye of the beholder, but take the original HTTP proposal. One page.
ONVIF is not just one page. It is a LOT of pages, a few concepts but a LOT of room to interpret things differently and mess things up (don’t forget to add developers tendency to make funny errors to the mix).
I am told that ONVIF is already creating problems in the real world. An NVR vendor recently announced that a new “Samsung ONVIF driver” was available. The idea that you write ONVIF drivers for particular vendors tells me that while ONVIF might not be broken per se, there are certainly problems pretty much across the board (please correct me if I am wrong).
ONVIF is really a great example of two problematic concepts. Design by committee and the second system effect. While the committee part is fairly obvious, the second system effect might need some clarification: Most people that participated in the committee had already had experience with simple HTTP based interfaces. Now, instead of picking the BEST parts, keeping it simple and then incrementally add functionality, they decided to make this the “mother of all rewrites”. No more simplistic HTTP, no, let’s go all out and throw the technology du jour at it. What about SOAP? Hell YEAH!! I guess the ONVIF guys could have chosen CORBA as well, because when CORBA was hot the community wanted to use CORBA for everything too.
Here’s one example of how the ONVIF committee, in my opinion, have compromised the user for the sake of the technology: Events are never pushed from the camera to the NVR, instead the NVR has to POLL for events. This may or may not be a problem, if you want your system to respond fast you need to poll more often. I think it is a poor design. I don’t need my app to act like a kid in the back seat asking me “are we there yet” every 30 seconds (or every second if you want something that seems a little closer to real time).
Now, I don’t pretend to know the motivation for this weird design and I suppose that there is some merit to it (I just don’t know what it would be). An alternative could have been a HTTP POST with some XPath and an expiration, the response would then be a multipart/mixed response, each payload corresponding to an event.
Don’t take this the wrong way, the ONVIF spec is a magnificent specimen of work, but I believe you have over-engineered the solution. All we needed was for you guys to agree on the same freaking URI to get video and we’d be done, instead we got something terribly complex that I believe will be too difficult for a lot of people to implement.