Hi ----- Original Message ----- > On Thu, Jan 14, 2016 at 08:23:01AM -0500, Marc-André Lureau wrote: > > > In this case, this protocol addition is local-only, and has only been > > > tested by few people, which does not make me very comfortable with > > > setting it in stone right now. So I'm asking if we should mark this as > > > > This is fud, like most protocol additions, when it's added, it has been > > tested by very few people. > > To me, the difference is that usually, the protocol additions have been > either minor, or for 'non-core' features. > Here we have a major change in the way display is handled, but still, this > work is only partial, as it's local only for now, so yes my feeling is that > we > should be extra careful with this. Adding a new compression method isn't a similar change for you? There is a capability flag, there is fairly explicit constrain on unix-socket, the server can provide backward compatibility. As a proof-of-concept, I can provide a server patch providing tcp socket / remoting by doing glreads from the framebuffer, but I hope I don't need to do that to convince you. This is the work for proper remoting that can be done later in a next step. Fast local graphics is already a big use case alone. > > > experimental somehow (but I don't have great suggestions about the > > > 'how'). > > > > If we had such a process, but I don't think it's necessary to create one > > for these messages. > > Does this mean you are 99.999% sure that in 3 years from now we'll still > be happily using these messages? This is just arbitrary numbers. What I know is this works well for the last year, and I don't expect it to need changes soon. Please let's stop spreading fear, we can do it today, and users are waiting. We will deal with iterative changes the same way as usual when necessary. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel