DLL vs SDK

"cybereality" wrote:
It's an interesting question, but ultimately it seems giving developers access to the SDK source code gives them the most flexibility in integrating with their applications.

How are having access to source and having the 'default SDK' be a standardized set of functions exported from a C friendly API as a DLL mutually exclusive?

Having the standard SDK be C++ is a mistake, forcing developers to statically link is a mistake. I mean just take the upcoming sdk which promises to fix Yaw drift correction, we could have all code out there support this *Instantly* by just copying a new DLL to the respective app's folder, yet now you pushed the responsibility to the developers, who may or may not still support that specific application. It's bad from a users perspective and i have to say it's bad from a developer perspective, you fix a bug, the developer gets to recompile and run their apps though a complete QA cycle to push an update out, gee thanks!

What IMHO *needs* to happen for successful and proper developer support:

1) Dump the C++ SDK, we all make mistakes, it's how we learn, no big deal.
2) Define a STRONG C API (Strong meaning, once the SDK supports a certain function it's signature or behavior can NEVER EVER change)
3) Deliver this as a DLL on windows and as a shared library on other platforms. (Forcing developers to statically link your code is bad, and you should feel bad)
4) Give developers the right to redistribute this dll with their application.
5) Optional: Release the source for this dll to developers to help them with debugging.

Yes it's a lot of work, and it requires putting a lot of forethought into it. It's also the method 99.99% of all other vendors use. Saying you "have the source, you figure it out, your problem now!" is a cop out, don't be lazy.

I Understand you guys are a new company, and as you grow you learn, but this should be one of those learning moments, and i truly truly hope you recognize it as such. It's not too late, you can still fix this.