Hi,
On 06/24/2013 02:39 PM, Daniel P. Berrange wrote:
On Mon, Jun 24, 2013 at 02:31:27PM +0200, Hans de Goede wrote:
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
gtk/channel-main.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 69 insertions(+), 4 deletions(-)
IIUC, implicit in your patch here is that the communication protocol
between spice client & guest agent uses guest OS specific line ending
markers, and the spice client must do all conversions to guest OS
format. Is that really what we want ?
Yes, this is by design. The reason for this is that there are no real
conventions as to what line-endings to use inside the clipboard data,
so ie the clipboard on unix (X) may contain text data with CRLF
line-endings. And some programs may depend on this.
So to minimize the change of breaking things we don't want to do any
conversion when doing copy and paste between a unix guest and unix client,
or a windows guest and windows client.
Personally I would have said that the line ending markers should be
invariant (always \n) in the comms protocol and that each end point
must handle conversion to/from \r\n if required.
That was my initial design too, but see above.
But perhaps there are backwards compat issues forcing your choice
here ?
Well currently we don't do any conversions, so keeping the wire
format in guest "encoding" makes things a bit easier wrt backward
compat handling, but we could have moved to always use \n on the
wire using guest capabilities bits, so that is not the main reason
for this.
Regards,
Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel