Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Christian B. <chr...@go...>]

Hi Fotis,

Nice to hear you're making progress!

Happy new year and answers inline :-)

Am Tue, 27 Dec 2016 21:11:15 +0200
schrieb Fotis Tsamis <ft...@gm...>:

> Hello,
> 
> Python LibVNCClient bindings is now my official assigned graduation
> project under Dr. Michail's (CC'd) supervision.
> 
> I have made some progress with the bindings, and I'm currently facing
> 2 implementation issues.
> 
> First, my client creation interface looks like:
> 
> client = RFBClient(8,3,4)   # calls rfbGetClient
> client.init_client([...])  # calls rfbInitClient
> 
> and a destructor which calls rfbClientCleanup when the object assigned
> to "client" is garbage collected.
> 
> 1) The first issue is that if rfbInitClient fails (I handle this
> raising a python exception), it also calls rfbClientCleanup which just
> free()s the rfbclient structure and I'm left with a python swig object
> which points to free'd memory.
> 
> My only reasonable approach to solve this is not using/wrapping
> rfbInitClient, and defining my own init_client (or maybe "connect" as
> a more describing name). Any other ideas?
> 

Another common approach is a per-object IsOk flag which is checked in every
method call and turns them into NOPs when set.

> 
> 2) The other issue is that there is no rfbDisconnectClient. The only
> way to disconnect a connected client using the libvncclient API is to
> destroy it altogether.
> 
> Since forcing python users to do "del client" to disconnect is not
> quite elegant in Python, is there any chance that such a function
> could be implemented upstream, and then rfbClientCleanup would call
> this? It wouldn't break backwards compatibility and it would make
> sense in C too to have a non-destructive disconnect function, I
> believe. I can make a pull request if necessary.

Go ahead! But pls make sure that the client struct is re-usable afterwards.

> 
> If you don't really like the idea, I think my only option would be to
> implement a disconnect method in the bindings level, calling FreeTLS
> there, which thankfully is safe to call more than once (the destructor
> would call it a second time).
> 
> 
> Kind Regards,
> Fotis