[Spice-devel] [PATCH spice-common] proto: Add agent features message

[Victor Toso]

Hi,

On Thu, Sep 15, 2016 at 09:01:30AM -0400, Marc-André Lureau wrote:
> Hi
>
> ----- Original Message -----
> > Hi,
> >
> > On Thu, Sep 15, 2016 at 08:18:38AM -0400, Marc-André Lureau wrote:
> > > > > Actually, there is agent capabilities, I think that's what the
> > > > > server should be overriding instead.
> > > >
> > > > I know that is possible but imo it is hack. It would be needed to
> > > > filter VD_AGENT_ANNOUNCE_CAPABILITIES from the agent, insert something
> > > > like VD_AGENT_CAP_FILE_XFER_DISABLED, VD_AGENT_CAP_COPY_PASTE_DISABLED
> > > > and also in the case that the filter is changed on the fly, it would
> > > > be needed to generate complete VD_AGENT_ANNOUNCE_CAPABILITIES (or
> > > > request agent to send them). I think it would be more complicated...
> > >
> > > I don't think it is so complicated, but I might be wrong. The server
> > > already parses some agents messages for filtering.
> > >
> > > At least I think it would be cleaner from the protocol POV. I don't
> > > see much benefit for the client to know that the server disabled
> > > something explicitely vs the agent not having the capability.
> >
> > I think we could do some distinction about agent capabilities and
> > features that are disabled on host and for that reason I think this
> > message makes sense from protocol POV.
>
> What differences does that make from a client? Do you think it helps
> much for the client to say "the feature foo has been disabled by the
> server" vs "the feature foo is not available"?

Well, with "feature is disabled" user can request a sysadmin to enable
it while with "feature not available" only, user will spam us saying
that vdagent is running fine, why it does not work? :)

> The are already many caps: common caps, channel caps, vdagent caps..
> Does the protocol need to grow yet another "agent_features"? That
> really seems redundant with vdagent caps.

As you said, it *can* be implemented with capabilities but that changes
the meaning of it. Agent is capable of doing file-transfer but the fact
that it is disabled by QEMU should be handled differently, IMHO.

AFAICT, what happens today is that client tries to file-transfer even if
file-transfer is disabled on server. Server ignores it. We could reply
with some server message saying that feature is disabled? We would still
need to improve protocol for that, I think.

  toso
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20160915/565cacb7/attachment-0001.sig>