Just recently there was a problem discovered in considered to be stable DirectShow component (the problem itself is not fatal – access violation while being used in improbable scenario – and thus it may appear it is even ignored), another “pleasant” thing came up with an API from another vendor.
The camera vendor is recognized in the industry and even considered to be among leaders, kind of “cheap for superior quality”. Their SDK/API has always been offered to reach several goals: the first was to cover product line with unified access method; the second was to embed implementation of a not so much popular TFTP protocol used for this type of hardware (rivals use more popular protocols: HTTP, RTSP). These not include regular things like to documented access to variety of features, availability for Win32 and Linux etc.
API documentation has always been not very much accurate as if it was given insufficient attention but luckily it was quite simple to figure things out. Another warning thing was that native software worked directly, without SDK: it was not very good for independent software vendors like us because there was a suspicion that SDK was something complimentary and was undertested. Fortunately however, the vendor decided to change this and their mainstream software started using the same SDK redistributables available for independent vendors also.
The first incident was recently when the vendor changed SDK implementation without changing published API and without giving any notice in documentation on one of the features. It did not break compilation or anything in our software, however it started working differently in production environment. We started receiving complaints and since we did not find any documentation changes, contacted the vendor’s support for comments and found out that implementation has been changed…
Now we got a new issue. As mentioned before, SDK’s advantage was to cover product line being constantly extended. New hardware from the product line appears to be quite sophisticated – a camera with multiple sensors. I believe this was not the thing foreseen when original SDK was designed so there was a kind of solution to workaround indexed access to individual sensor parameters in the API. However it appeared now that new products don’t support some of the older product features and SDK instead of returning a kind of “unsupported” error code to the requests, instead it messes other values. So it appeared that unified access to the product line was broken…
Everything was finally sorted out but in total it took a lot of time to. First of all, the problem due to its nature spread to production from where the dealer started receiving complaints from his client. The dealer in his turn forwarded the issue to us where we had problems investigating it because this particular piece of hardware is a kind of rare and expensive. When we gather sufficient data to think of the case as an SDK bug we forwarded the issue to the vendor.
Obviously the vendor responded with ridiculous suggestions assuming us to be complete lamers. Still we were in position to help our client and resolve the case, so spent some time to gather additional information to prove the supposition of an SDK bug. It took quite some time at our expense while finally we could work out a workaround for the problem and soon after receive a confirmation for a bug… Can we expect it to be fixed with next SDK update? “We will do this some time later”.
Why things happen this way? OK we are a small ISV with our own problems getting things work as expected. The vendor, however, is a high technology leader, well known and recognized throughout the industry, a subject of a completely different scale. Expensive hardware ans software is involved and we are still getting ridiculous problems at the output.