[DISCUSS] Support for proprietary libraries

[Mike Jumper <mj...@apache.org>]

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

Re: [DISCUSS] Support for proprietary libraries

[Nick Couchman <vn...@apache.org>]

On Thu, Aug 8, 2019 at 3:38 PM Mike Jumper <mj...@apache.org> wrote:

> 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?
>
>
I have no issue with having the compile support included in our code for
attaching to other SDKs - I'm all for flexibility and allowing the end
user/admin/developer to choose their route, and supporting whatever we can
within our code, so long as it stays within ASF rules and doesn't have any
adverse impacts on the default code, I don't see any reason not to.  We can
always provide some heavy caveats within the manual and/or readme files
that say, "You can do this, but performance is going to suck and you'll run
into problem XYZ."  Someone will still rant at us on the mailing list about
it, but if it helps out the community and increases the number of people
who can use it, then why not?

-Nick