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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel