On 11/08/2013 01:11 AM, Marc-André Lureau wrote:
On Thu, Nov 7, 2013 at 11:58 PM, Uri Lublin <uril@xxxxxxxxxx> wrote:
On 11/08/2013 12:37 AM, Marc-André Lureau wrote:
On Thu, Nov 7, 2013 at 11:17 PM, Uri Lublin <uril@xxxxxxxxxx> wrote:
On 11/06/2013 10:07 PM, Marc-André Lureau wrote:
Add an optional message sent by the client to ask the agent not to send
clipboard data bigger than a certain size, in bytes. The message can be
sent if the agent supports the capability MAX_CLIPBOARD, at any time.
The agent is free to ignore or forget the value after a restart or a
disconnection, but a bigger message might be discarded when received on
client side, resulting in bandwidth waste.
Hi Marc-Andre,
Maybe better if they negotiate that size -- each report its supported max
and
the min max is picked.
I don't think that make so much sense.
If the client crash for OOM reason (which it shouldn't afaik, it is
quite OOM-safe), it should be restarted automatically anyway.
Furthermore, I think it's better if the client has full control over
the setting, and not be limited by guest configuration which he could
change.
If really this is necessary for some obscure reason that I don't
forsee, I'd see that as a future protocol capability.
I just thought that if it can crash the client, it's possible it can crash
the agent too.
Specifically I'm thinking of a Linux client and Windows agent.
Yes, it could eventually crash at any end point if they are not oom.
That's the point of this message, to set a limit globally. Imho,
further negotiation just complicates things for no clear benefit. Any
the whole thing is not even guaranteed at any side, it's almost
impossible to deal with OOM! it's just a little hint for setting. The
client can say "I know I am never going to use a clipboard of 100mb,
so just don't try". It's not actually about being OOM safe, it's more
of a preference which has a nice side effect of avoiding crash in some
cases.
OK, let's add this message and if needed we can add negotiation later.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel