libvncserver icon indicating copy to clipboard operation
libvncserver copied to clipboard

Identify client from rfbClientLog and rfbClientErr

Open learn-more opened this issue 3 months ago • 6 comments

Currently it is not possible to identify which client is logging something.

The way I see it, there are at least two options to solve this:

  1. Move rfbClientLog and rfbClientErr into the client (remove the globals)
  2. Add a client argument to these functions.

Are you interested in either of these options?

There should probably be a fallback to the current system, unless you don't mind a breaking change?

learn-more avatar Sep 19 '25 11:09 learn-more

Yep, I know of that shortcoming. If at all, it should be a separate logging function to not break API. At least not now ;-)

bk138 avatar Sep 19 '25 11:09 bk138

Yep, I know of that shortcoming. If at all, it should be a separate logging function to not break API. At least not now ;-)

If we introduce a new function that falls back to the old function, that allows to update the code and provide extra info for 'up to date' clients.

Would you entertain a PR implementing this or do you prefer to handle it yourself?

learn-more avatar Sep 19 '25 11:09 learn-more

If we introduce a new function that falls back to the old function, that allows to update the code and provide extra info for 'up to date' clients.

Would you entertain a PR implementing this or do you prefer to handle it yourself?

Would fancy the PR as it's less work :-)

bk138 avatar Sep 19 '25 12:09 bk138

If we introduce a new function that falls back to the old function, that allows to update the code and provide extra info for 'up to date' clients. Would you entertain a PR implementing this or do you prefer to handle it yourself?

Would fancy the PR as it's less work :-)

A quick and dirty (global search/replace) and fixing up some compile errors gives an idea of the extent of changes: https://github.com/LibVNC/libvncserver/pull/676

And sadly quite a bit of the interface in rfbclient.h needs to be changed to accommodate this.

Considering you did not want to break the API, how should we proceed? Shelve this for now, or do you want to proceed anyway?

learn-more avatar Sep 19 '25 20:09 learn-more

If at some point, someone want to take it up, well then yes. It's not a high prio.

bk138 avatar Sep 20 '25 17:09 bk138

@learn-more if you want, you could help out at https://github.com/bk138/multivnc/issues/261 - IIRC this also needs some work in libvncclient.

bk138 avatar Sep 20 '25 18:09 bk138