<div dir="ltr"><div><div>Hello Zeeshan, Marc-André and other Spice developers,<br><br></div>I think about implementing a solution for this bug 62033 (<a href="https://bugs.freedesktop.org/show_bug.cgi?id=62033">https://bugs.freedesktop.org/show_bug.cgi?id=62033</a>). <br>
<br></div>First of all, need to clarify what is requested and what is really needed in this request. Zeeshan suggests as a simple yet acceptable solution for vdagent to report 'local-only' connection non-dynamically.. as I understand this means reporting only once, at startup (?). I think it isn't enough because this connection state may change easily during X session lifetime - in general user is free to connect locally and then re-connect from remote host, and vise versa. So I propose more generic approach, when vdagent reports current connection state dynamically when state is changed. It will be up to gnome-settings-daemon to act on this signal and toggle animations accordingly.<br>
<div><div><br></div><div>If this is acceptable, we need to decide on the interface. I think there are 2 appropriate technologies:<br></div><div>1. raw socket [or something like this]<br></div><div>2. D-Bus<br></div><div><br>
</div><div>I'm not an expert in D-Bus and freedesktop in general (good opportunity for me to learn!) but looks like it is appropriate to use it here. 2 questions arise:<br></div><div>1. vdagentd and vdagent daemons already communicate via socket using simple homebrew protocol (at least afaik). Probably this was done on purpose. So is it true vdagent wants to avoid dependency on D-Bus? <br>
</div><div>2. It seems to better use some higher-level D-Bus bindings (GLib, Qt...) instead of its low-level API. So is it acceptable to add a dependency of GLib to vdagent? Or are you aware of some other D-Bus bindings to be used in vdagent to avoid this extra dependency?<br>
<br></div><div>BTW, reporting of connection state can be implemented independently of the actual transport (socket/D-Bus):<br></div><div>1. Client app (e.g. gnome-settings-daemon) establishes connection to vdagent being a server (e.g. listening at the socket, or providing D-Bus interface method RegisterConnectionStateObserver or w/e we name it)<br>
</div><div>2. vdagent sends the state to registered clients (e.g. D-Bus signal); and continues to do so each time the state is changed.<br></div><div>So we can even have 2 back-ends for this (additional work, unfortunately).<br>
<br></div><div>And last question: while this isn't needed on Windows version of vdagent right now, additional use cases of this vdagent interface in guest userspace may arise [e.g. I'm thinking about remote media engine provided by spice client]. So I think we should target for similar extendable interface at both Windows and Linux guests (as much as possible). I haven't looked in vdagent for Windows code yet but guess D-Bus won't be the best choice there (while D-Bus reportedly works on Windows as well...). Something like socket and D-Bus and native DCOM would be the best and future-proof.. What do you think?<br>
<br></div><div>[Note: I haven't talked about implementation of new messages between vdagent and vdagentd, and spice-server, and the actual local/remote detection code - will ask questions later]<br></div><div><br><div>
<div>-- <br>Best regards,<br>Fedor
</div></div></div></div></div>