On Fri, 2009-12-11 at 13:38 -0600, Anthony Liguori wrote: > Mark McLoughlin wrote: > > On Fri, 2009-12-11 at 13:04 -0600, Anthony Liguori wrote: > > > >> But to introduce another protocol where a user has to make a choice to > >> use Spice over VNC, I think we need a really good justification for > >> that. It's really about complexity. A user shouldn't have to know > >> about Spice or VNC. They shouldn't have to contemplate the trade-offs > >> of whether their management tool is aware or not. It should Just Work. > >> > > > > That's a good goal. > > > > If we add a new protocol, we could achieve the same thing by allowing > > qemu support both VNC and Spice at runtime. Then you just need a client > > like virt-viewer that can handle both protocols, and old VNC clients > > will continue to be able to connect to newer qemu. > > > > Supporting them at the same time could be potentially challenging. You > would need to render Spice locally in qemu in order to expose it via vnc. > > Another nasty bit is that two protocols mean two different sets of > authentication mechanisms. Does Spice support SASL based > authentication? Could it make sense to essentially tunnel Spice through > vnc in order to reuse the existing authentication infrastructure?
I don't doubt there are challenges. I think your requirement that old clients work with new servers and new clients work with old servers is a good one. Maybe extending VNC is the best way to get there, but it should be recognized there is another way of achieving the same thing if Spice does require a new protocol. The underlying goal is getting lost in the "Spice can't be a VNC extension" discussion :-) Cheers, Mark.
