Hello all, Some time ago, I was tasked at my day job with adding support for the RealVNC SDK as an alternative to libvncclient. This was not due to some inherent advantage of that SDK, but due to a proprietary encryption scheme required by some RealVNC servers which only their SDK implements.
I was able to do this through abstracting away the VNC backend, letting the build process select between the two. It does work, but I immediately ran into problems which lead me to believe it wouldn't be acceptable here (upstream): 1) The RealVNC library lacks callbacks which expose the nature of updates received, including whether the mouse cursor has changed or whether CopyRect is used. This means VNC support using the SDK will always be slower than libvncclient, and there is effectively no local mouse cursor (only remote). 2) Licensing of the SDK is such that I'm unsure what would be required for people to build against it as part of normal development, including CI via the ASF Jenkins. 3) The SDK will not allow direct TCP connections at all unless a special "add-on code" is purchased to activate that rather fundamental feature. So ... on one hand, some may appreciate the support if they are in the position where they are forced to use the SDK because of the proprietary encryption. On the other hand, building against the SDK produces VNC support which will not perform as well, may be tricky to arrange for general testing and CI, and requires an "add-on code" in order to be useful even if you have the SDK. Thoughts? - Mike
