On 12.12.2009, at 01:53, Izik Eidus wrote: > On Sat, 12 Dec 2009 01:27:09 +0100 > Alexander Graf <ag...@suse.de> wrote: > >> >> On 12.12.2009, at 01:14, Izik Eidus wrote: >> >>> On Sat, 12 Dec 2009 00:54:47 +0100 >>> Alexander Graf <ag...@suse.de> wrote: >>> >>>> >>>> On 11.12.2009, at 23:46, Izik Eidus wrote: >>>> >>>>> On Fri, 11 Dec 2009 23:08:01 +0100 >>>>> Alexander Graf <ag...@suse.de> wrote: >>>>> >>>>>> >>>>>> On 11.12.2009, at 22:13, Izik Eidus wrote: >>>>>> >>>>>>> On Fri, 11 Dec 2009 14:46:55 -0600 >>>>>>> Anthony Liguori <anth...@codemonkey.ws> wrote: >>>>>>> >>>>>>>> Izik Eidus wrote: >>>>>>>>> I personaly dont like mjpeg, and yes in the end of the day you >>>>>>>>> can add the video streaming into vnc, but what is the point >>>>>>>>> here? >>>>>>>>> >>>>>>>> >>>>>>>> What I'm trying to understand is, what can we do with Spice >>>>>>>> that we couldn't possibly do with vnc. That means >>>>>>>> understanding each feature and then figuring out if there's a >>>>>>>> vnc analog. >>>>>>>> >>>>>>>> If there are compellingly unique features to Spice that can't >>>>>>>> be duplicated in vnc, then it's a no brainer. If you can do >>>>>>>> most things in vnc but it would be hackish whereas Spice makes >>>>>>>> it all elegant, then provided we can merge Spice without a >>>>>>>> huge amount of pain, then it's a net win. >>>>>>>> >>>>>>>> However, if we need to make a few changes to vnc in order to >>>>>>>> get the same performance as Spice, then it's not quite as >>>>>>>> clear that it's what we should be using. >>>>>>>> >>>>>>>> We're talking about a major change here. There is a ton of >>>>>>>> management software that assumes vnc today. Even though there >>>>>>>> are Spice clients out there, there are embedded vnc clients in >>>>>>>> certain tools today along with java applets. >>>>>>>> >>>>>>>> That's not to say we shouldn't embrace Spice, we just have to >>>>>>>> make sure we have a good reason to. >>>>>>> >>>>>>> Ok, I understand your concerns. >>>>>>> >>>>>>> But even though that spice and vnc achive in the end of the day >>>>>>> the same thing - they both allow remote rendering, they have >>>>>>> fendumental diffrent architacture. >>>>>>> >>>>>>> Spice server work with a ring to the guest, it was build from >>>>>>> day one to work like that, In addition it was built from day >>>>>>> one so that the server will render only what it must to render >>>>>>> (to allow much higher virtualization denticity). >>>>>> >>>>>> The ring is from qemu <-> guest, right? I mean, qemu <-> client >>>>>> would be a TCP transport anyways, so the ring argument is void. >>>>> >>>>> >>>>> Beside the fact that we dont have the network overhead... >>>> >>>> Eh - when you connect to the VM remotely you still get the network >>>> overhead, because you're connecting to it via the network :-). >>> >>> Yes but you send the data from the HOST networking, not from the >>> virtualized guest networking (That will later send it from the Host >>> networking)... >> >> Exactly. So you'd get the same as with virtio-fb and VNC :-). > > Yes, virtio-fb and spice have the same overhead for the ring part, > but this not what i understood when you said: > "The ring is from qemu <-> guest, right? I mean, qemu <-> client > would be a TCP transport anyways, so the ring argument is void."
Oh one of your arguments about the superiority of SPICE was that it uses a ring buffer. I just wanted to make sure you're talking about the guest <-> hypervisor interface there, thus not stressing anything in the SPICE protocol :-). > > But leave it :). > >> >>> >>> >>>> >>>>> >>>>>> >>>>>>> Just to make clear how much spice is diffrence from VNC is by >>>>>>> the fact that only the library itself (not including the >>>>>>> drivers) have 128,277 lines of code inside it. (In my old qemu >>>>>>> repo i see almost 600,000 lines for qemu) so this should give >>>>>>> better prespective on how much spice is diffrent from vnc. >>>>>>> >>>>>>> So ofcurse in theory you can take all this 128,000 lines and >>>>>>> push them into qemu-vnc.c ?, but you got to remember that spice >>>>>>> is not just specific qemu thing, Spice should be used to work >>>>>>> on physical machines too, just cutting all this lines of code >>>>>>> from spice and throw it into qemu-vnc.c will be meaning a fork >>>>>>> of spice inside qemu.... >>>>>> >>>>>> I definitely understand your point of having a single protocol. >>>>>> The good news is that your physical machine stuff isn't released >>>>>> yet (AFAIK), so luckily there's still time to change parts of the >>>>>> protocol :-). >>>>>> >>>>>>> It isnt just the rings and the rendering style that make spice >>>>>>> diffrence, it is the channels it have for each compoment, it is >>>>>>> the multiple drawing surfaces, and so on... >>>>>> >>>>>> These should be fairly easy to implement in VNC too. In fact, I >>>>>> remember a project implementing off-screen drawing in VNC using a >>>>>> larger region of the screen than what was visible and then >>>>>> copyrect them in. >>>>> >>>>> In theory you can even change the whole of VNC into SPICE or the >>>>> whole of VI into EMACS, so???, I personaly think changing code >>>>> isnt the problem, the problem is always the desgien, and SPICE >>>>> have fandumental diffrent desgien than VNC, (Here you can say: OK >>>>> I can make my VNC desgien like SPICE, or you can say I think >>>>> SPICE dsgien is bad, or you can just use SPICE...) >>>> >>>> Oh I'm not trying to talk you or anyone into anything. I was merely >>>> trying to stress that SPICE isn't really its own protocol but >>>> extensions to the RDP protocol (IIUC). You could do similar >>>> extensions to VNC if you liked. Thus I'd love to see a generic >>>> mid-layer and implementations of RDP and VNC on top of that >>>> actually. >>> >>> One of the decisions we have made in SPICE, was to provide a full >>> functional remote system, not realying on other system, >>> We already have far more features than VNC have, so what is the >>> logical in making spice extention of VNC? it more logical to make >>> VNC extention of SPICE... >>> >>> SPICE have networking tunneling, local/server mouse, (in progress) >>> usb remote, audio / recording channel , private channels for each >>> compoment, Even if VNC would have part of this stuff, It seems like >>> they are trying to achive things in diffrent way than SPICE does. >> >> It kind of reminds me of the vbus story ;-). >> > We are not forking qemu, we are self depended protocol, we have the > right to implment the protocol the best way as we understand, I don`t > see much connection with the VBus case... > > The real interesting part is, that we not forcing any changes to qemu, > we dont say "throw" vnc, we just add another protocol, that users > already are using and are very happy. > check out: > > http://www.brianmadden.com/blogs/brianmadden/archive/2009/12/10/red-hat-makes-the-qumranet-spice-protocol-open-source-a-free-alternative-to-ica-pcoip.aspx > > Why is it that bad to allow user freedom of choice for whatever > protocol it want to use for its remote system? Nothing at all! I want to make it even more modular. I want to see a lego like approach where we can combine all the good parts together and use whatever we like from whatever corner we come from. So the thing I dislike is the "take all of QXL and SPICE or leave everything" sort of attitude that's coming over. I'd love to use QXL, but I don't want to use SPICE :-). Thus I want to make sure we're going in a really modular direction, so all the bits can be combined to every users' liking. Thus creating choice. Alex